Hello,
First time getting parity errors. Got 7 errors (run without correction). I had two disks with minor (my opinion) SMART warnings, older (no warnings during the parity check):
Parity#2: 199 UDMA CRC Error count = 1

DataDisk#5: 188 Command timeout count = 1

Shutdown server, replaced SATA cables (just in case), started a new parity check overnight (no error corrections) and in the morning at about 30% the error count was again 7. SMART errors did not change.

I spent 2 hours reading official docs and older posts, and I am not clear on the following:
Is there a way to find out what sectors/location of the disks the errors are? Consequently, any tool that can tell me what files are written at those sectors?

Ultimate goal is to check the file(s) before checking parity again with error correction. Array drives are XFS file system. I am currently in the process of setting up back server, so at the moment I don't have a good backup to automated compare (no file hashing). I will admit, I haven't educated myself enough on that front, so if you have a good tip where to start - I will take it. But primary focus is how to properly check current files integrity.

Edited April 25Apr 25 by OrdinaryButt

please post diagnostics

5 hours ago, OrdinaryButt said:

Is there a way to find out what sectors/location of the disks the errors are? Consequently, any tool that can tell me what files are written at those sectors?

The sector numbers are given in the syslog, but there is no way of knowing which drive caused the issue or which file(s) may be affected.

The only way to check data integrity if using XFS as the file system for array disks is to have checksums for the files previously generated using something like the File Integrity plugin.

If you had been using btrfs or ZFS then these file systems have built-in check-summing so could identify files affected. Even with these you would still have to restore good copies from your backups.

2 hours ago, itimpi said:

The sector numbers are given in the syslog, but there is no way of knowing which drive caused the issue or which file(s) may be affected.

The only way to check data integrity if using XFS as the file system for array disks is to have checksums for the files previously generated using something like the File Integrity plugin.

If you had been using btrfs or ZFS then these file systems have built-in check-summing so could identify files affected. Even with these you would still have to restore good copies from your backups.

I have enough hard drives (for the back up server) to use as temporary data swap, should I consider formatting my array hard drives to ZFS to improve future robustness? ZFS was not available when I started Unraid adventure.

Edited April 25Apr 25 by OrdinaryButt

3 hours ago, itimpi said:

something like the File Integrity plugin.

Haven't used this new plugin myself but I am familiar with par2, which is how usenet binaries (nzb) are able to be reconstructed from incomplete data.

7 hours ago, OrdinaryButt said:

I have enough hard drives (for the back up server) to use as temporary data swap, should I consider formatting my array hard drives to ZFS to improve future robustness? ZFS was not available when I started Unraid adventure.

ZFS is not recommended for use in the main Unraid array as it does not perform well when used there (this does not apply to ZFS used in pools). Whether this will be solved for a future Unraid release I have no idea. If you want to switch to a checksumming file system in the main Unraid array then BTRFS would make more sense.

Having said that XFS is still the preferred file system for the main array as it is deemed more robust against failures. There is the File Integrity plugin available if you want checksums kept on a XFS system.

In all cases you should still have backups of any important data.

6 hours ago, trurl said:

Haven't used this new plugin myself but I am familiar with par2, which is how usenet binaries (nzb) are able to be reconstructed from incomplete data.

par2 is not about keeping checksums for each individual file, but about protecting a file set and providing recovery data for when files in the set are damaged.

Note that checksumming does not in itself give recovery capability - it merely allows you to identify damaged files. The checksums are stored as file attributes and effectively consume no additional space. You still need to recover damaged files from backups.

17 hours ago, MowMdown said:

please post diagnostics

Here you go. I had to wait for the second parity check to complete, and it did it finished last night with the same 7 errors.

qsc-diagnostics-20260426-1248.zip

Apr 24 21:06:20 QSC kernel: mdcmd (36): check nocorrect

Until you run a correcting parity check you will continue to get those same sync errors.

19 minutes ago, trurl said:

Apr 24 21:06:20 QSC kernel: mdcmd (36): check nocorrect

Until you run a correcting parity check you will continue to get those same sync errors.

I am aware. I did my second parity check without correction to see if the changed SATA cables will have any effect (or if SMART errors will increase). And didn't want to correct, before I research possible way to find which files are affected. It sounds like there is no way to find that out, as I have not used file integrity plugin/check summing of any sort.

Did you have unclean shutdown before that previous parity check?

On 4/26/2026 at 4:19 PM, trurl said:

Did you have unclean shutdown before that previous parity check?

I don't think so, cause if the shut down is unclean, doesn't it force you to do parity check on first array start or is there a situation where the force may be skipped? I had one event where the server took over 10 minutes to shut down, with zero output to HDMI console, so I couldn't see what was going on, but eventually shut down.