Well it looks like metadata corruption, if it were just a case of data
corruption there'd be a file name path associated with the checksum
mismatch error; and in that case you'd be able to just delete the file
(or first extract a copy of it it with btrfs restore) and then it
wouldn't trigger csum
The problem with that strategy in my case is that I can't get a handle
on what the inode that triggers the problem is. As a result I don't
know which files/directories I would need to delete and restore from
backup later on to make the scrub/balance succeed. From the first post
>>>
I ran this all off my personal machine, so whenever it locked up I
just forced a power cycle, I did this probably more than a dozen
times. I think the link below is the one I used to translate innodes
into file names for me to delete and restore from backups (in addition
to the files that where
Thanks for the response Justin. This is exactly what I tried before
posting to the list, but it doesn't seem to get me anywhere. The
moment I hit the logical address that is flagged up in btrfs check as
problematic the balancing operation just sits there and does nothing,
but the operation also
I converted my significantly smaller raid 5 array to raid 1 a little
less than a year ago now and I encountered some similar issues.
What i ended up doing was starting balance again and again with
slightly different arguments (usually thresholds for what blocks to
move) and eventually (a week or
Following the recent posts on the mailing list I'm trying to convert a
running raid5 system to raid1. This conversion fails to complete with
checksum verify failures. Running a scrub does not fix these checksum
failures and moreover scrub itself aborts after ~9TB (despite repeated
tries).
All
