January 23, 20179 yr It seems a disk was fried by the power outage, as unRAID detected 39 errors on a single disk (but none on the others) the moment I started the array up again. Unfortunately, several seconds passed before I was able to cancel the parity check, and 1 parity "error" at sector 123720 was unfortunately "corrected" as a result. How can I find out which file was occupying this sector?
January 23, 20179 yr I'm not aware of any easy way. It should be possible to view the target bytes with a hex editor viewing the raw disk data at that address, but it would be a tough task to pin down which file those bytes belong to.
January 23, 20179 yr Author I'm not aware of any easy way. It should be possible to view the target bytes with a hex editor viewing the raw disk data at that address, but it would be a tough task to pin down which file those bytes belong to. Hmm, I suppose a hex editor wouldn't be able to show what the previous value was? The goal is to either 1) Correct the data or 2) Just replace the entire file with a copy from backup, so I'm not particularly interested in viewing the corrupted data itself...
January 23, 20179 yr Author The backed up data is scattered across the cloud (2016 onwards), an external HDD (2014-2016), and a spindle of BD-REs (2013 and older). It would take days to download/gather everything together, filter out duplicates, and then vet the data. Doesn't ReiserFS have any inode reverse lookup tools? Given that this kind of thing takes less than 10 minutes to query out on ext3/ext4 even when doing the math for block-sector mapping by hand, I'm kinda surprised to hear that there's nothing similar for ReiserFS.
January 23, 20179 yr Community Expert Are you sure it was corrected? Starting on unRAID v6.2.3 a parity check following an unclean shutdown is no correct.
Archived
This topic is now archived and is closed to further replies.