I have been using snapraid wrong all this while I think.
This is a sample of typical file error, where the file is corrupted during a copy or bitrot.
error:2365656:u2:Users/photo/Panasonic LX5/20180916/IMG_3892.JPG: Data error at position 3, diff bits 65/128
status:damaged:u2:Users/photo/Panasonic LX5/20180916/IMG_3892.JPG
error:5554388:u2:Users/photo/iPhone 6s/20200226/IMG_4817.JPG: Data error at position 2, diff bits 65/128
status:damaged:u2:Users/photo/iPhone 6s/20200226/IMG_4817.JPG
msg:status:
msg:status: 2 errors
msg:fatal: WARNING! There are errors!
I had been trying "fix -e" and always comes back with no error found. Then I realised maybe I should not have used "-e" as it is suppose to fix "bad blocks". Silly me!
Questions:
1) What does the error look like when it's a bad block? Does snapraid log where those BLOCK errors are during a scrub and that's how it can target those exact blocks using "fix -e"?
2) What is the best way to fix and re-check those exact 2 files errors? I tried using filters to limit the fix and check but they are not very efficient as there are many folders or files with exact same names. When I try to narrow it down the filter by with disk and folder/filename combined it doesn't work.
***snapraid check -d u2 -f "iPhone 6s/20200226/IMG4817.JPG"
Suggestion: Can snapraid log the damaged file errors so that it can target those exact files using "fix" and "check"? Alternatively, maybe allow full path filters. I would prefer the latter simply for the flexibility throughout Snapraid but the former for the convenience.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is your problem in chronological order:
1. Perfectly good files are correctly read during snapraid sync.
2. Perfectly good files are incorrectly read during snapraid scrub.
3. Perfectly good files are correctly read during snapraid fix resulting in nothing to do.
Snapraid scrub verifies that the content of the files has not changed after the files were synced.
If a difference is found snapraid will make a note of it in the content file so that you can later run snapraid fix -e.
The blocks listed by snapraid in the error message has nothing to do with the blocks and sectors used by the hard drive to physically store data on the disk. It is just a logical reference to which part of the file was found to have corrupted / unexpected data.
I had been trying "fix -e" and always comes back with no error found. Then I realised maybe I should not have used "-e" as it is suppose to fix "bad blocks". Silly me!
If you want to fix a corrupted file found by scrub then the correct command to do so is fix -e.
However in this case you don't have any corrupted files. Instead you have faulty hardware resulting in the not corrupted files randomly turning up as corrupted in the RAM memory where snapraid is looking at it.
It is almost always caused by a bad memory stick, a bad disk controller or using a Firewire cable,
Iphone 6 is not supposed to use firewire, but maybe you have some thunderbolt to firewire adapter cable introducing random corruption? At least that would be my main suspect.
You can log the results from scrub, check, fix and sync via the -l logfile.txt parameter.
If there is an error snapraid will tell you which files are affected.
Full path filter is already allowed (from snapraids perspective).
This should for example work:
snapraid check -d u2 -f "/Users/photo/iPhone 6s/20200226/IMG_4817.JPG"
Last edit: Leifi Plomeros 2020-06-27
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Good to know I have been using "fix -e" correctly but confused why it doesn't seem to work for me. This is not the first time I encountered this and raised on this forum before. The conclusion then was bad ram/non-ECC and I left it as that. This time I reran "check" and also used independent hash files and multipar to confirm errors were real corruptions, not on the fly memory corruptions.
This is actually what happened, I use "-l" for every snapraid command so I always have a complete log. This is great advice by the way and I got from someone on this forum. (maybe you!)
Perfectly good files are correctly read during snapraid sync.
Perfectly good files are correctly read during snapraid scrub, no errors.
Migrated data disk, but perfectly good files were incorrectly copied over, resulting in errors on new data disk. (dodgy SMR drives perhaps?)
Bad files (on the new data disk) are correctly read during snapraid "check -a" , hence file errors found.
Bad files are (correctly or incorrectly) read during snapraid "-e fix" but no errors found resulting in nothing to do.
msg:progress: Initializing...
msg:progress: Fixing...
msg:status: Nothing to do
msg:status: Everything OK
summary:error:0
summary:errorrecovered:0
summary:errorunrecoverable:0
summary:exit:o
To confirm it's not a ECC/bad RAM error. I reran snapraid check (this time with folder filter to reduce time taken), again identical errors were found.
Recalced hash file and multipar. Both double confirmed bad files were actually bad.
Manually re-copied the good file from old data disk and replaced bad files on new data disk. (could have used multipar to fix but didn't want to change the timestamp)
Recalced hash and multipar. Both confirmed files are now good.
Rerun snapraid check (with filter) and no errors found.
Where have I gone wrong here? Is there an easy way to intentionally "damage" a file so I can figure out why it's not working? I have to get to the bottom of this once and for all.
As for filters, Iooks like mine failed due to lack of the initial "/". I will test that later once my scrub is done.
Last edit: alabama 2020-06-27
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
3> Unlikely to be caused by dodgy SMR drives since they (and all modern hard drives) use internal CRC to prevent that and are expected to refuse to deliver any corrupted data.
4+5> Only sync and scrub flags corrupted data blocks in order for check -e and fix -e to find them.
6> What typically happens is correct data sent from source disk --> corruption occurs in transit --> corrupted data gets written to target disk. From target disk perspective the file is not corrupted, since it was written exactly as it was received.
The easiest way to intentially corrupt a file for test purpose is to modify a text file and then restore the last modified time to the time expected by snapraid.
To find out the the time expected by snapraid you can use snapraid list -v >list.txt (-v is important to get sub second part of the time stamps)
To set the time stamp you can use this powershell command:
An alternative method in Windows:
1. Use Disk Manager to create a couple of virtual disks (a few GB each).
2. Setup snapraid on the virtual disks (make extra sure to not make a conflict with content files for your normal snapraid array).
3. Put a text file with the text Donald Duck in it on the virtual data disk.
4. Sync
5. Unount the virtual data disk (to make the host file writable)
6. Use HxD or any other hex editor to search for Donald in the file containing the virtual data disk.
7. Change Donald to Ronald in HxD.
8. Mount the virtual data disk again.
9. Make snapraid find the corruption.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have been using snapraid wrong all this while I think.
This is a sample of typical file error, where the file is corrupted during a copy or bitrot.
error:2365656:u2:Users/photo/Panasonic LX5/20180916/IMG_3892.JPG: Data error at position 3, diff bits 65/128
status:damaged:u2:Users/photo/Panasonic LX5/20180916/IMG_3892.JPG
error:5554388:u2:Users/photo/iPhone 6s/20200226/IMG_4817.JPG: Data error at position 2, diff bits 65/128
status:damaged:u2:Users/photo/iPhone 6s/20200226/IMG_4817.JPG
msg:status:
msg:status: 2 errors
msg:fatal: WARNING! There are errors!
I had been trying "fix -e" and always comes back with no error found. Then I realised maybe I should not have used "-e" as it is suppose to fix "bad blocks". Silly me!
Questions:
1) What does the error look like when it's a bad block? Does snapraid log where those BLOCK errors are during a scrub and that's how it can target those exact blocks using "fix -e"?
2) What is the best way to fix and re-check those exact 2 files errors? I tried using filters to limit the fix and check but they are not very efficient as there are many folders or files with exact same names. When I try to narrow it down the filter by with disk and folder/filename combined it doesn't work.
***snapraid check -d u2 -f "iPhone 6s/20200226/IMG4817.JPG"
Suggestion: Can snapraid log the damaged file errors so that it can target those exact files using "fix" and "check"? Alternatively, maybe allow full path filters. I would prefer the latter simply for the flexibility throughout Snapraid but the former for the convenience.
This is your problem in chronological order:
1. Perfectly good files are correctly read during snapraid sync.
2. Perfectly good files are incorrectly read during snapraid scrub.
3. Perfectly good files are correctly read during snapraid fix resulting in nothing to do.
Snapraid scrub verifies that the content of the files has not changed after the files were synced.
If a difference is found snapraid will make a note of it in the content file so that you can later run snapraid fix -e.
The blocks listed by snapraid in the error message has nothing to do with the blocks and sectors used by the hard drive to physically store data on the disk. It is just a logical reference to which part of the file was found to have corrupted / unexpected data.
If you want to fix a corrupted file found by scrub then the correct command to do so is fix -e.
However in this case you don't have any corrupted files. Instead you have faulty hardware resulting in the not corrupted files randomly turning up as corrupted in the RAM memory where snapraid is looking at it.
It is almost always caused by a bad memory stick, a bad disk controller or using a Firewire cable,
Iphone 6 is not supposed to use firewire, but maybe you have some thunderbolt to firewire adapter cable introducing random corruption? At least that would be my main suspect.
You can log the results from scrub, check, fix and sync via the -l logfile.txt parameter.
If there is an error snapraid will tell you which files are affected.
Full path filter is already allowed (from snapraids perspective).
This should for example work:
snapraid check -d u2 -f "/Users/photo/iPhone 6s/20200226/IMG_4817.JPG"
Last edit: Leifi Plomeros 2020-06-27
Hi again Leifi,
Good to know I have been using "fix -e" correctly but confused why it doesn't seem to work for me. This is not the first time I encountered this and raised on this forum before. The conclusion then was bad ram/non-ECC and I left it as that. This time I reran "check" and also used independent hash files and multipar to confirm errors were real corruptions, not on the fly memory corruptions.
This is actually what happened, I use "-l" for every snapraid command so I always have a complete log. This is great advice by the way and I got from someone on this forum. (maybe you!)
Bad files are (correctly or incorrectly) read during snapraid "-e fix" but no errors found resulting in nothing to do.
msg:progress: Initializing...
msg:progress: Fixing...
msg:status: Nothing to do
msg:status: Everything OK
summary:error:0
summary:errorrecovered:0
summary:errorunrecoverable:0
summary:exit:o
To confirm it's not a ECC/bad RAM error. I reran snapraid check (this time with folder filter to reduce time taken), again identical errors were found.
Where have I gone wrong here? Is there an easy way to intentionally "damage" a file so I can figure out why it's not working? I have to get to the bottom of this once and for all.
As for filters, Iooks like mine failed due to lack of the initial "/". I will test that later once my scrub is done.
Last edit: alabama 2020-06-27
3> Unlikely to be caused by dodgy SMR drives since they (and all modern hard drives) use internal CRC to prevent that and are expected to refuse to deliver any corrupted data.
4+5> Only sync and scrub flags corrupted data blocks in order for check -e and fix -e to find them.
6> What typically happens is correct data sent from source disk --> corruption occurs in transit --> corrupted data gets written to target disk. From target disk perspective the file is not corrupted, since it was written exactly as it was received.
The easiest way to intentially corrupt a file for test purpose is to modify a text file and then restore the last modified time to the time expected by snapraid.
To find out the the time expected by snapraid you can use snapraid list -v >list.txt (-v is important to get sub second part of the time stamps)
To set the time stamp you can use this powershell command:
An alternative method in Windows:
1. Use Disk Manager to create a couple of virtual disks (a few GB each).
2. Setup snapraid on the virtual disks (make extra sure to not make a conflict with content files for your normal snapraid array).
3. Put a text file with the text Donald Duck in it on the virtual data disk.
4. Sync
5. Unount the virtual data disk (to make the host file writable)
6. Use HxD or any other hex editor to search for Donald in the file containing the virtual data disk.
7. Change Donald to Ronald in HxD.
8. Mount the virtual data disk again.
9. Make snapraid find the corruption.