RedCow

Yes, if the drive errors on reading the data back and thus you know which drive is a problem, that drive's data can be restored from parity (I run two parity); however, the silent type of data error would not be recoverable since you would not know which drive(s) have invalid data -- all you would know is that something may be wrong during array party checking/verification, but not able to recover without knowing which bit is trustworthy from which drive. I am very surprised to hear you handle large quantities of data without encountering this silent data corruption -- I have encountered it myself a fair few times in video files getting corruption out of nowhere, zip and 7z archives which no longer extract at all, and others. Regardless of your and my own personal experience, silent data corruption is a known and studied phenomenon -- it's not something I'm making up. If you have any doubt regarding this, read the details about "silent data corruption" here: https://queue.acm.org/detail.cfm?id=1866298 Maybe you value your write speeds, but I would gladly give up 50% of my write speed (or even 75%) to get read-back-verification on the cache mover in unRAID. It would be a checkbox and be optional anyway, so you could just opt to not use it. Also keep in mind you wouldn't lose performance as long as you're not writing more than your cache pool's data size. This would be the mover taking some extra time in the middle of the night to move these files. I would really like to see someone from unRAID staff chime in on this -- I want this on the roadmap or a good reason why it's not needed (which I don't believe exists). I'm assuming the mover is some kind of simple application like linux cp or windows xcopy (which has a /v flag to do read-back-verify). This shouldn't be too hard to implement.

Right, what I'm saying is that you don't find out if your data is safe until you read it back. Many times hard disks will write without knowing/reporting any issues and they don't crop up until you actually try to read it back. This, IMO, makes the mover not verifying that what it has moved is readable a pretty bad design choice for data integrity.

I have also had many instances of drives that happily write, but when you read back, that's when you find out your drive is going bad. You hit a bad sector, the read stops to a halt, your SMART "pending sector reallocation count" goes up, and if you've already deleted the source file, your data is gone. I understand we're writing to an array with parity, but I think that the mover having an option to perform read-back verification before deleting something off the cache is pretty important...

I use TeraCopy to move files from drive<->drive / machine<->machine with "Always Verify" enabled. This means that after a copy or move all of the written data gets read back and verified before removing files from the source disk/machine. You would be surprised how many times this has saved my ass due to inconsistencies discovered -- I have moved 100's of TBs of data. There have been instances where data written to a hard disk finished happily but when verified the CRC was different with no errors anywhere to be seen. This leads me to my concern: I currently have no Cache in my unRAID setup so that I can be sure TeraCopy is verifying the files as they are written on disk are indeed correct; however, if I add a Cache volume this verification will essentially become 'worthless' unless the mover in unRAID which moves from Cache to Array also performs such verification. Does the unRAID mover perform CRC or hash checking when moving files from Cache to the Array? If not... this seems like a critical issue for file integrity.