Robert Munteanu wrote on 2015/07/30 16:16 +0300:
The disk image (still) contains sensitive data so I can't share it
unfortunately. What I can do is keep it untouched until Friday evening
EEST and run any debugging commands that you might think of to trace
down the source of the errors. Alternatively, if there's an easy and
safe fix and debugging is not worth it, I'm happy to apply that fix as
well.
Based on the results of running btrfs check --repair on an image file
taken from the actual disk I ran a btrfs check --repair on the
physical partition
The output was ( again, re-typed so might contain typos )
# btfrs check --repair /dev/sda1
enabling repair mode
repair mode will force to clear out log tree, Are you sure [y/N]: y
Checking filesystem on /dev/sda1
UUID: ...
checking extents
Fixed 0 roots.
checking free space cache.
cache and super generation don't match, space cache will be invalidated
checking fs roots
Fixed discount file extends for inode: 14214570 in root: 5
root 5 inode 14214570 errors 100, file extend discount
Found file extent holes:
Fixed discount file extends for inode: 14214570 in root: 5
root 5 inode 14214570 errors 100, file extend discount
Found file extent holes:
Any full output about it?
Not sure if it real loops, but maybe the inode number changed in later
output?
Thanks,
Qu
The previous 3 lines repeat a lot, every 10 seconds maybe. After 30
minutes I got bored and stopped the process, as it looks like it's
looping at some condition that without making any progress. At any
rate, something worked well and I can now mount the volume again from
the rescue disk and boot from a read-only snapshot.
Cheers,
Robert
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
