Agreed, bad news. I was not sure how to test it myself, hence I asked.
Maybe ezechiel1917 can tell us how he tested it? (I'm guessing it's possible if one were to edit the raw files in the disks by removing them from the raid or so and make sure that the modified date is the same?)
I'm not really sure what is meant with this..what kind of validation is done by the update task? If it actually verifies the checksum then I'll breathe a sigh of relief, but from one of the threads it seems like it only checked to see that the files still exists?
I can only agree in asking very politely for a clear answer on this. (And to add my vote to please consider adding at least the option to enable a validate on all files involved in an update-task).
You can test this scenario by (hex) editing an existing file (leaving any file attributes untouched
) which is part of a parity block which will be updated by next Update. (You can find out which parity blocks will be updated just by running an update with a test new file which is about to be included and check the log for all files that are actually processed during it)
If you run such an update (with this edited file and a new file) it finishes successfully without any warning.
Delete this edited file, recover it from parity and it recovers it in it's edited version with a warning that it is corrupted (FlexRAID knows healthy CRC checksum of unedited version).
Now you'll know something went wrong, but at this point you have no chance to do anything about it since it is propagated to parity already.
I think what Brahim simply meant is what he said in his previous sentence. In other words that Update will prevent recalculating PPU if there is general problem with any of DRU paths (failed drive/path not connected etc.)