On Jan 15, 2014, at 8:15 AM, Marc MERLIN <m...@merlins.org> wrote: > On Wed, Jan 15, 2014 at 08:53:55AM +0100, Holger Brandsmeier wrote: >> # 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) > > I've been seeing this quite a bit too. Is this fixed already, or known > broken? > > I can run under gdb next time if needed.
I don't know. That alone might be worth a bz on kernel.org. If you do I'd also put the URL in this thread. And then also try building btrfs-progs from the integration branch, and seeing if it's still reproducible and include that information in the bug as well. > # 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. That last message is confusing. I'd say failed because your metadata allocation was much bigger than 1.3MB. If you build new progs from integration branch it might be worth filing this as a separate bug from recovery/repair attempt bug. > 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`. Archives contain some information on the consequences of those options. I'm pretty sure even if they work enough to let you mount the file system (to grab a more recent backup) that you will need to start over with a new file system. Before you do that I would file a bug for what you've done thus far, with the description being everything you've done, in order, up to this point. What kernel, what progs, that you started with btrfsck --repair, etc. The smartctl output as an attachment, and the dmesg you posted earlier showing the (likely) metadata repair after the read error. Then upgrade to kernel 3.13rc8 because I can't tell you if any Btrfs changes since 3.12.7 will fix this problem or not and chances are it will be asked anyway. Retry mounting normally, then with -o recovery, -o ro,recovery and report on those results in the bug. Include user spaces messages and dmesg. If that doesn't work, I would build btrfs-progs from integration branch and try the user space options in the order in Hugo's email. And report those results in the bug. If you get the btrfs-zero-log crash that's probably worth a separate gdb attachment before going on to anything btrfs repair (btrfsck) related. At any time before btrfs repair you can bail out, include right now, with btrfs restore. https://btrfs.wiki.kernel.org/index.php/Restore Grab what you can, and then blow away the file system. But I think you might have an interesting case because something this broken is inherently valuable, especially if it was btrfs repair that made it worse. Chris Murphy -- 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
