Ilgrank

Thanks for your kind reply Andrea That's kind of weird, but would explain why the bad blocks disappeared and why no matter what I did, there was no trace of them anymore. Next time this should happen, I think the best I can do is save a copy of the 'damaged' files, fix them, and do a file compare to check if corruption really did happen and in which proportions Many thanks, and thanks for all the commits you're doing towards 15.0 release!

update: after reading carefully the docs, I'm even more convinced that I am missing something: once a block is marked as bad, (if I understand correctly) a sync should ignore the bad blocks in regards to updating the parity. To sum up the events in a comprehensible manner: 1- ran snapraid sync from cli (no logs, alas), 11 data errors found. I have just the list of bad blocks and the path of just one of the corrupted files from what's left in the console 2- ran snapraid sync (scheduled helper script)...

update: after reading carefully the docs, I'm even more convinced that I am missing something: once a block is marked as bad, (if I understand correctly) a sync should ignore the bad blocks in regards to updating the parity. To sum up the events in a comprehensible manner: 1- ran snapraid sync from cli (no logs, alas), 11 data errors found. I have just the list of bad blocks and the path of just one of the corrupted files from what's left in the console 2- ran snapraid sync (scheduled helper script)...

update: after reading carefully the docs, I'm even more convinced that I am missing something: once a block is marked as bad, (if I understand correctly) a sync should ignore the bad blocks in regards to updating the parity. To sum up the events in a comprehensible manner: 1- ran snapraid sync from cli (no logs, alas), 11 data errors found. I have just the list of bad blocks and the path of just one of the corrupted files from what's left in the console 2- ran snapraid sync (scheduled helper script)...

update: after reading carefully the docs, I'm even more convinced that I am missing something: once a block is marked as bad, (if I understand correctly) a sync should ignore the bad blocks in regards to updating the parity. To sum up the events in a comprehensible manner: ran snapraid sync from cli (no logs, alas), 11 data errors found. I have just the list of bad blocks and the path of just one of the corrupted files from what's left in the console ran snapraid sync (scheduled helper script) next...

update: after reading and re-reading the docs, I'm even more convinced that I am missing something: once a block is marked as bad, if I understand correctly, even running the sync command it should be ignored in regards to updating the parity. To sum up the events in a comprehensible manner: ran snapraid sync from cli (no logs, alas), 11 data errors found. I have just the list of bad blocks and the path of just one of the corrupted files from what's left in the console ran snapraid sync (scheduled...

update: after reading and re-reading the docs, I'm even more convinced that I am missing something: once a block is marked as bad, if I understand correctly, even running the sync command it should still be left 'alone' and not put back into the parity file. To sum up the events in a comprehensible manner: ran snapraid sync from cli (no logs, alas), 11 data errors found. I have just the list of bad blocks and the path of just one of the corrupted files from what's left in the console ran snapraid...

update: after reading and re-reading the docs, I'm even more convinced that I am missing something: once a block is marked as bad, if I understand correctly, even running the sync command it should still be left 'alone' and not put back into the parity file. Yet, running a check and a fix -e, in the logs I have no trace of the bad blocks anymore, or of the -fix actually fixing anything ... probably it's best if I keep my hands tied until someone helps me sort this out :) To sum up the events: ran...