Yup, that is exactly the case. I got to know about no support of fsck.btrfs at boot up, so symlinked btrfsck and built the initrd. I will try to re-build without btrfsck now and try. Thanks for you quick reply and solution, Herald. thanks, ~shripadr On Sun, Apr 7, 2013 at 7:32 AM, Harald Glatt <mail@xxxxxxxxx> wrote: > 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
