gnollo

Notice [TOWER] - Data-Rebuild finished (0 errors)Duration: 1 day, 5 hours, 45 minutes, 18 seconds. Average speed: 74.7 MB/s

Data rebuild in progress

Last SMART test result: Completed without error

Ok so moving the disk from the previous slot in the Norco S500 caddi to a different norco S500 caddy, this one fed by a Sata cable from the motherboard (the other one comes from a 8 sata port card). Will check the disk Smart report next.

I had the same, with the same drive, twice, disabled because of read errors. I believe I actually moved it to a different slot to eliminate cabling issues. I was thinking of rebooting, moving a disk with no issues to a differnt empty slot and then rebuild the drive onto the slot that was occupied by the disk with no issues. Any objections? Also will run a smart test and share it before doing so. Any other suggestions welcome.

7 weeks later, 12 drives moved to XFS format, 68TB copied from drive to drive Removed drive 12 from the excluded list in Global Shares setting Turned Tunable (md_write_method) back to Auto in Settings>>Disk Settings Back in business, unless I have forgotten any other settings that need to be changed back? Thank you all for all your help and advice.

Ok so I followed the steps above and I am now ready to move the data over to disk 12 again, this time from disk 7. Couple of points 1) I was lucky that when I started the array again after switching the drives it recognised all the rfs disks as rfs, because clicking on the disk to change the mode from auto to rfs is no longer an option in this version of the OS 2) this time I had the option to format the drive to XFS, which was much faster than CLEAR process I had to use for the parity drive last week. Why did I not get the option to format the parity drive instead of clear?

sent 11.48M bytes received 308.27K bytes 18.43K bytes/sec total size is 9.11T speedup is 773,026.16 Check completed some time earlier today so pretty quick in comparison to the previous checsum attempt. TTerminal returned to the root@tower green command line. I will swap the disks, format the rfs one to xfs and start moving the next drive.

OK started the drive post move check using TTerminal with rsync -avhPX /mnt/disk4/ /mnt/disk12/ I can now see the files being listed one by one as it goes through Thank you all for your help.

No issues, first time that I get that message so I thought to share for those who have not upgraded to the latest version of unraid. Additional steps were listed on https://docs.unraid.net/go/convert-reiser-and-xfs I don't copy them all as I added the link above and the text is quite long.

Updated unraid to latest version, 7.2.3, and now I get a message about "Critical: Deprecated Filesystem The following array devices are using deprecated filesystems:" list of all my rfs drives Action Required: Migrate to a supported filesystem (XFS v5, BTRFS, or ZFS). View migration guide → Message on the guide is Any drives formatted in ReiserFS need to be migrated to another filesystem ASAP as they will not be usable in future releases of Unraid. Any drives formatted in older XFS versions need to be migrated before 2030. The only method recommended there is Via the WebGUI (Unraid 7.2+): Navigate to Main → Array Operation and stop the array Navigate to Settings → Global Share Settings. In the Emptying disk(s) area, select the disk(s) to empty and Apply. Note: this status will automatically be removed when the array is stopped. In Unraid 7.2.0, any data on this disk will be hidden from user shares until this status is removed. Starting with Unraid 7.2.1, the data remains available to user shares but new files will not be written to the disk until this status is removed. Navigate to Main → Array Operation and start the array On Main → Array Operation click Move (or wait until mover runs via its normal schedule) Mover will empty the disk, moving files to other array drives according to your Share settings. Note that files at the root of the drive are outside of any Shares and will not be moved. Check Tools → System Log for messages about any files that could not be moved due to being in use or a lack of free space

I have rebooted the server to clear all activities and restart the emby docker, as my family was rioting after one week of askimg me are we there yet? So I will restart the comparison on Sunday night to complete the check. I am going to go with -avhPX as I feel that the checksum comparison might be overkill, probably takes much longer than the command above. If you think I should have the checksum as part of the final comparison before I wipe the source drive, let me know your thoughts please.

The window timestamp at the bottom is changing in line with the time on the server, which leads me to believe is still running. Also I cannot type anything on that window, so I think this means it is still running?

CPU usage very low now, but no message on the console. I think it must have finished? very annoying, has been a week now.

So thank you for the links, did a bit of research to compare the two group of commands 1) -avhPX So a summary for what the command switches above do: -a = -rlptgoD (preserves the permissions, timestamps, symbolic links, and other attributes of the files.) the -a command does the following -r = Recurse into directories -l = Copy symlinks as symlinks -p = Preserve permissions -t = Preserve modification times -g = Preserve group -o = Preserve owner -D = preserve device and special files files (super-user only) and -v = verbose (every action is written out) -h = output numbers in a human-readable format,show progress during transfer -P = resumes partial transfers combining --partial and --progress, resuming partial transfers in case a previous sync is interrupted, and showing the current transfer progress of all files, respectively -X = preserve extended attributes 2) -rcvPX -r = Recurse into directories -c = skip based on checksum, not mod-time & size -v = verbose -P = resumes partial transfers -X = preserve extended attributes So from where I am standing the biggest differences between the two is one inclused a checksum comparison, is that slowing down the process? the other one includes -h which outputs numbers in readable formadn and is supposed to show progress during transfer Interestingly both include -v but I am not seeing any text on the screen, This is what I found about the -c command, -c, --checksum This changes the way rsync checks if the files have been changed and are in need of a transfer. Without this option, rsync uses a lqquick checkrq that (by default) checks if each file's size and time of last modification match between the sender and receiver. This option changes this to compare a 128-bit checksum for each file that has a matching size. Generating the checksums means that both sides will expend a lot of disk I/O reading all the data in the files in the transfer (and this is prior to any reading that will be done to transfer changed files), so this can slow things down significantly. The sending side generates its checksums while it is doing the file-system scan that builds the list of the available files. The receiver generates its checksums when it is scanning for changed files, and will checksum any file that has the same size as the corresponding sender's file: files with either a changed size or a changed checksum are selected for transfer. Note that rsync always verifies that each transferred file was correctly reconstructed on the receiving side by checking a whole-file checksum that is generated as the file is transferred, but that automatic after-the-transfer verification has nothing to do with this option's before-the-transfer lq Does this file need to be updated? rq check. For protocol 30 and beyond (first supported in 3.0.0), the checksum used is MD5. For older protocols, the checksum used is MD4.