In summary:
Looks like minimal damage remains and yet I'm still suffering
Input/output error from btrfs and btrfsck appears to have looped...
A diff check suggests the damage to be in one (heavily linked to) tree
of a few MBytes.
Would a scrub clear out the damaged trees?
Worth debugging?
Any clues or educated comment please?
Can the corrupt directory tree safely be ignored and left in place? Or
might that cause everything to fall over in a big heap as soon as I try
to write data again?
Could these other tricks work-around or fix the corrupt tree:
Run a scrub?
Make a snapshot
On Oct 7, 2013, at 8:56 AM, Martin m_bt...@ml1.co.uk wrote:
Or try mount -o recovery,noatime again?
Because of this: free space inode generation (0) did not match free space cache
generation (1607)
Try mount option clear_cache. You could then use iotop to make sure the
btrfs-freespace
