> 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: 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 -- http://robert.muntea.nu/ -- 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
