On Sun, Apr 7, 2013 at 3:56 AM, Shripad Ratnaparkhi <shripad.ratnaparkhi@xxxxxxxxx> wrote: > [Replying to my own email] > > Found a patch which seems to be discusses the fix in a patch provided here: > https://patchwork.kernel.org/patch/1946561/ > > Still now sure whether that is already there in v0.20-rc1 or > applicable to fix my issue. > > thanks, > ~shripadr > > PS: BCC'ing the patch provider. > > On Sun, Apr 7, 2013 at 7:16 AM, Shripad Ratnaparkhi > <shripad.ratnaparkhi@xxxxxxxxx> wrote: >> Hi there, >> I am newbie and recently started using btrfs. Now facing a weird problem. >> >> FWIW, I am on archlinux, kenel v3.8.0, having Btrfs v0.20-rc1. >> After an abnormal reboot, getting these errors while boot: >> >> systemd.fsck[289]: checking extents >> systemd.fsck[289]: checking fs roots >> systemd.fsck[289]: checking root refs >> systemd.fsck[289]: found 23728128 bytes used err is 0 >> systemd.fsck[289]: total csum bytes: 23092 >> systemd.fsck[289]: total tree bytes: 81920 >> systemd.fsck[289]: total fs tree bytes: 24576 >> systemd.fsck[289]: btree space waste bytes: 38038 >> systemd.fsck[289]: file data blocks allocated: 23646208 >> systemd.fsck[289]: referenced 23646208 >> systemd.fsck[289]: Btrfs v0.20-rc1 >> [ OK ] Started File System Check on /dev/sda1. >> Mounting /boot... >> systemd.fsck[289]: checking extents >> [ OK ] Mounted /boot. >> [ OK ] Reached target Sound Card. >> systemd.fsck[289]: checking fs roots >> systemd.fsck[289]: checking root refs >> systemd.fsck[289]: extent buffer leak: start 206893056 len 4096 >> systemd.fsck[289]: *** Error in `fsck.btrfs`: corrupted double-linked >> list: 0x0000000002081d80 *** >> >> and its not proceeding and stuck here. >> I have the rescue disk handy, but not sure how can I fix this issue. >> Any help please. >> >> thanks, >> >> -- >> ~shripadr > -- > 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 The version that you can get from btrfs doesn't say a whole lot sadly. You can build the newest tools from git and try with the btrfsck there. Now this might not be entirely correct, but as far as I know the btrfsck tool isn't ready to be used in the traditional fsck capacity (automatically at bootup, etc). They don't symlink the tool on arch and per default arch builds it's initrd without a fsck for btrfs available. If you manually symlinked the tool to get rid of that error message during initrd creation I'd suggestion removing that symlink again and rebuilding your initrd without a btrfsck in place. As far as I know the best and most reliable way at the moment to confirm or repair errors is by btrfs scrub. Once you removed the startup fsck it might boot normally. You can then start a scrub with 'btrfs scrub start /' and see its status and progress via 'btrfs scrub status /'. If the scrub reports no errors, or finds some but repairs them, that is (as far as I know) a more reliable message than whatever btrfsck thinks. -- 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
