Allyn Malventano

If a drive has just one folder present in its SnapRAID path and the contents within that folder were modified, SnapRAID throws a warning and fails to begin sync, as it believe that 'all the files present have been rewritten' when in reality that is not the case. Yes, the only directory present in the root had its attributes changed, but the contents of the drive are not all rewritten (in my example only a few files were moved around and none were deleted at all). Since SnapRAID had already scanned...

If a drive has just one folder present in its SnapRAID path and the contents within that folder were modified, SnapRAID throws a warning and fails to begin sync, as it believe that 'all the files present have been rewritten' when in reality that is not the case. Yes, the only directory present in the root had its attributes changed, but the contents of the drive are not all rewritten (in my example only a few files were moved around and none were deleted at all). Since SnapRAID had already scanned...

I've tested this on Windows but not yet on Linux. I suspect the behavior is similar: Delete a file. Recover deleted file with 'snapraid fix -f FILE'. Note file date and time reflect the original date/time at the time of the last sync. The above is expected, however this only works properly for deleted files: Modify a file. Overwrite the modified file, restoring its prior state with 'snapraid fix -f FILE'. Note the newer (revised) file date and time remains, even though the contents have reverted...

I've tested this on Windows but not yet on Linux. I suspect the behavior is similar: 1. Delete a file. 2. Recover deleted file with 'snapraid fix -f FILE'. 3. Note file date and time reflect the original date/time at the time of the last sync. The above is expected, however this only works properly for deleted files: 1. Modify a file. 2. Overwrite the modified file, restoring its prior state with 'snapraid fix -f FILE'. 3. Note the newer (revised) file date and time remains, even though the contents...

I've tested this on Windows but not yet on Linux. I suspect the behavior is similar: Delete a file. Recover deleted file with 'snapraid fix -f FILE'. Note file date and time reflect the original date/time at the time of the last sync. The above is expected, however this only works properly for deleted files: Modify a file. Overwrite the modified file, restoring its prior state with 'snapraid fix -f FILE'. Note the newer (revised) file date and time remains, even though the contents have reverted...

Given the long rebuild times for a missing/failed disk, some files on the remaining disks might be moved or relocated during the rebuild. When SnapRAID runs into a file that was relocated after the rebuild started, it aborts with the following message: DANGER! file '(file name here)' disappeared. If you moved it, please rerun the same command. I understand the caution and the desire to abort for this case, but if there was sufficient additional parity to continue even with a missing file, is there...

There are a few other read/write operations that I've noted to not 'line up' with 1MB block devices: Loading state from snapraid.content (even from SSD this appears slower than it should be - likely 128K reads based on my observations). When using blocksize 1024, data disk reads appear to be aligned, however parity disks are seeing ~20% additional write requests than expected to the disk, suggesting that parity file writes might not be aligned to the configured blocksize. Is there some header information...

There are a few other read/write operations that I've noted to not 'line up' with 1MB block devices: Loading state from snapraid.content (even from SSD this appears slower than it should be - likely 128K reads). When using blocksize 1024, data disk reads appear to be aligned, however parity disks are seeing ~20% additional write requests than expected to the disk, suggesting that parity file writes might not be aligned to the configured blocksize. Is there some header information in the parity files...