+linux-btrfs@xxxxxxxxxxxxxxx I am not sure if # btrfs-image -c9 -t4 /dev/sda5 /some/path parent transid verify failed on 602529792 wanted 23460 found 23463 parent transid verify failed on 602529792 wanted 23460 found 23463 parent transid verify failed on 602529792 wanted 23460 found 23463 parent transid verify failed on 602529792 wanted 23460 found 23463 Ignoring transid failure Error going to next leaf -5 create failed (Success) means this failed or succeeded, it wrote a file which is 1.3mb large. # mount -orecovery /dev/sda5 data/ or # mount -orecovery,ro /dev/sda5 data/ didn't succeed with the output after timestamp 8670.468771 in dmesg.out # btrfs-zero-log /dev/sda5 parent transid verify failed on 602529792 wanted 23460 found 23463 parent transid verify failed on 602529792 wanted 23460 found 23463 parent transid verify failed on 602529792 wanted 23460 found 23463 parent transid verify failed on 602529792 wanted 23460 found 23463 Ignoring transid failure btrfs-zero-log: disk-io.c:155: readahead_tree_block: Assertion `!(ret)' failed. Aborted (core dumped) with not much dmesg output at timestamp 8975.683197 I attached the outputs of # btrfsck /dev/sda5 > btrfsck_s0.out 2>&1 # btrfsck /dev/sda5 --super=1 > btrfsck_s1.out 2>&1 The two files differ, but to me they both look equally bad. Should I try `btrfs-select-super` or `btrfsck --repair --init-extent-tree` / `btrfsck --repair --init-csum-tree`. Thanks, Holger On Wed, Jan 15, 2014 at 5:06 AM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > > On Jan 14, 2014, at 4:24 PM, Holger Brandsmeier <brandsmeier@xxxxxxxxx> wrote: > >> Dear Chris, >> >> as requested: >> >> # btrfs fi show >> Label: none uuid: 267f069c-11da-4d2a-88fa-00cab4e28149 >> Total devices 1 FS bytes used 12.68GiB >> devid 1 size 29.82GiB used 24.27GiB path /dev/sdb1 >> Label: none uuid: f6907d81-f46f-4911-8600-858e8b6bd1a0 >> Total devices 1 FS bytes used 141.72GiB >> devid 1 size 278.00GiB used 212.04GiB path /dev/sda5 >> Btrfs v3.12 >> >> The problem makes `/dev/sda5`. I attached the output of `smartctl -x /dev/sda5`. > > There are some reallocated sectors. dmesg reports > [ 2023.770828] btrfs read error corrected: ino 1 off 605564928 (dev /dev/sda5 sector 1199128) > > That might be metadata on a bad sector that was fixed from duplicate metadata. This is single device Btrfs with default DUP metadata? > >> >> # mount -o clear_cache /dev/sda5 data/ >> mount: wrong fs type, bad option, bad superblock on /dev/sda5, >> missing codepage or helper program, or other error >> > > Hmm. So maybe the 1st superblock is no good. But it might be worth trying btrfs-zero-log first. It's possible the repair made this worse. > > https://www.mail-archive.com/linux-btrfs@xxxxxxxxxxxxxxx/msg27613.html > > > > Chris Murphy > > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
