"corrupt leaf" on kernel 3.17.2, w/ btrfs-progs 3.17
My rootfs on /dev/sda2 (an SSD) shows this:
Nov 06 15:37:26 hiro.oops.intern kernel: BTRFS critical (device sda2):
corrupt leaf, slot offset bad: block=100235100160,root=1, slot=142
Scrub runs through fine:
# btrfs scr stat /dev/sda2 scrub status for ea95dbd1-ef4e-48a4-9732-54e6c80b31df scrub started at Thu Nov 6 15:35:00 2014, running for 172 seconds total bytes scrubbed: 68.46GiB with 0 errors
Do I have to panic? ;-)
Pls advise how to proceed.
Should I do some repair or btrfsck from a live-medium?
I found this:
http://comments.gmane.org/gmane.comp.file-systems.btrfs/34407
but haven't yet figured out what that means to me.
# btrfs version Btrfs v3.17
# cat /proc/version Linux version 3.17.2-gentoo ([email protected]) (gcc version 4.8.3 (Gentoo 4.8.3 p1.1, pie-0.5.9) ) #1 SMP Thu Nov 6 00:53:58 CET 2014
Stefan
Am 06.11.2014 um 15:45 schrieb Stefan G. Weichinger:
Quoted 3 lines
Pls advise how to proceed.
Should I do some repair or btrfsck from a live-medium?
... had some hefty kernel crashes ...
Now I am on latest sysresccd.
btrfsck v 3.16 ... fails as well
Backing up.
Seems I have to recreate the btrfs (with 3.16?) and all its subvolumes ... *sigh*
Maybe the SSD dies?
S
Am 06.11.2014 um 17:11 schrieb Stefan G. Weichinger:
Quoted 6 lines
Am 06.11.2014 um 15:45 schrieb Stefan G. Weichinger:
Quoted 3 lines
Pls advise how to proceed.
Should I do some repair or btrfsck from a live-medium?
Quoted 7 lines
... had some hefty kernel crashes ...
Now I am on latest sysresccd.
btrfsck v 3.16 ... fails as well
Backing up.
While I am rsyncing I get this again in dmesg:
btrfs: corrupt leaf, slot offset bad: block ...
btrfs no csum found for inode ...
Can I determine which subvol this relates to?
As far as I understand it is likely the one currently synced?
Maybe I could only recreate that one subvolume and restore?
Or do I have to recreate the whole btrfs?
S
Copied a tarball of btrfs-progs v 3.17-r1 over and ran:
btrfs check --repair /dev/sda2
it tells me
incorrect offsets 12499 blabla
items overlap, can't fix
cmds-check.c:2918 fix_item_offset: Assertion ret failed
... and crashes
Any help appreciated!
restoring from backup now