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 and work from the snapshot? Or try "mount -o recovery,noatime" again? Or is it dead? (The 1.5TB of backup data is replicated elsewhere but it would be good to rescue this version rather than completely redo from scratch. Especially so for the sake of just a few MBytes of one corrupt directory tree.) Thanks, Martin On 05/10/13 14:18, Martin wrote: > So... > > The hint there is "btrfsck: extent-tree.c:2736", so trying: > > btrfsck --repair --init-extent-tree /dev/sdc > > That ran for a while until: > > kernel: btrfsck[16610]: segfault at cc ip 000000000041d2a7 sp > 00007fffd2c2d710 error 4 in btrfsck[400000+4d000] > > There's no other messages in the syslog. > > The output attached. > > > What next? > > > Thanks, > Martin > > > > On 05/10/13 12:32, Martin wrote: >> No comment so blindly trying: >> >> btrfsck --repair /dev/sdc >> >> gave the following abort: >> >> btrfsck: extent-tree.c:2736: alloc_reserved_tree_block: Assertion >> `!(ret)' failed. >> >> Full output attached. >> >> >> All on: >> >> 3.11.2-gentoo >> Btrfs v0.20-rc1-358-g194aa4a >> >> For a 2TB single HDD formatted with defaults. >> >> >> What next? >> >> Thanks, >> Martin >> >> >> >> >>>> In the meantime, trying: >>>> >>>> btrfsck /dev/sdc >>>> >>>> gave the following output + abort: >>>> >>>> parent transid verify failed on 915444523008 wanted 16974 found 13021 >>>> Ignoring transid failure >>>> btrfsck: cmds-check.c:1066: process_file_extent: Assertion `!(rec->ino >>>> != key->objectid || rec->refs > 1)' failed. >>>> id not match free space cache generation (1625) >>>> free space inode generation (0) did not match free space cache >>>> generation (1607) >>>> free space inode generation (0) did not match free space cache >>>> generation (1604) >>>> free space inode generation (0) did not match free space cache >>>> generation (1606) >>>> free space inode generation (0) did not match free space cache >>>> generation (1620) >>>> free space inode generation (0) did not match free space cache >>>> generation (1626) >>>> free space inode generation (0) did not match free space cache >>>> generation (1609) >>>> free space inode generation (0) did not match free space cache >>>> generation (1653) >>>> free space inode generation (0) did not match free space cache >>>> generation (1628) >>>> free space inode generation (0) did not match free space cache >>>> generation (1628) >>>> free space inode generation (0) did not match free space cache >>>> generation (1649) >>>> >>>> >>>> (There was no syslog output.) >>>> >>>> Full btrfsck listing attached. >>>> >>>> >>>> Suggestions please? >>>> >>>> Thanks, >>>> Martin -- 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
