I'm setting up this system and I just finished loading the first main chunk of data onto it. It was on a 4 disk USB enclosure so I plugged it into the system, mounted it, and used cp commands from the on machine terminal to copy the data to the /mnt/user/whatevershare folder. Doing this unRAID happily distributed the files across the various disks as per my share settings. Now I'm double checking the data (since I'm going to wipe the old drives and repurpose them) and I kicked off a parity sync.

 

The sync is still running but it's past the used point of all but 1 disk and it's found 1231 sync errors. That seams like a lot, I was expecting 0. So I'm definitely going to run a 2nd sync before I wipe these drives but the question is how did it get so high. Could any of these caused it?

 

During the copy a scheduled sync started (set to go on the first of the month) and I canceled it. The goal was copy the data faster and I was going to run a fresh sync after anyway.

 

During the copy a few times I didn't like that it split something up so I used putty and did an mv command to move it from /mnt/disk1 to /mnt/disk2

 

Another time during the copy I started to do a mv but then changed my mind so I ctrl+c it but it left the partial file it was working on behind so I did an rm on the partial.

 

I have already checked all files were copied from a file name and size perspective, I'm checking contents now but it's going to take a couple days. I'm just concerned about the parity errors and am wondering if doing things from the console might have been at fault. I'll try to remember to kick off a 2nd sync in the morning to see if this happens again.

out of curiosity what was the source when you used the cp commands? I know unRAID only likes disk to disk OR share to share moves. Meaning you can't move something from disk to share or share to disk. That causes a lot of issues. 

 

5 hours ago, davep1553 said:

Could any of these caused it?

No, most likely some hardware issues, digas might help.

On 1/4/2021 at 1:14 AM, adminmat said:

out of curiosity what was the source when you used the cp commands?

The source was a USB enclosure, mounted via terminal to /mnt/usb2. So the cmds were "cp -r /mnt/usb2/somefolder/. /mnt/user/someshare"

I still need to go back and fix the file ownership since it made root the owner of everything though.

So the 2nd parity check finished with no errors. My double check of the data is progressing albeit something is throttling it (there may be a separate post on that latter)

All the drives were old but healthy when the processes started but two have developed smart errors since and I'll be replacing one as soon as the double check is finished (since the old source will provide a replacement drive) Diagnostics attached

dvdvault-diagnostics-20210105-1902.zip

1 hour ago, davep1553 said:

a USB enclosure, mounted via terminal to /mnt/usb2

The usual way to do this is with the Unassigned Devices plugin. Creating things yourself in /mnt at the command line is not recommended and won't survive reboot.

There are multiple read errors on disk1, which appears to be failing, that likely explains the sync errors.