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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Shripad Ratnaparkhi
2013-Apr-07 01:56 UTC
Re: [BUG] btrfs.fsck failing to fix corrupted block
[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@gmail.com> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Apr 7, 2013 at 3:56 AM, Shripad Ratnaparkhi <shripad.ratnaparkhi@gmail.com> 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@gmail.com> 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@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.htmlThe 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Shripad Ratnaparkhi
2013-Apr-07 02:11 UTC
Re: [BUG] btrfs.fsck failing to fix corrupted block
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@hachre.de> wrote:> On Sun, Apr 7, 2013 at 3:56 AM, Shripad Ratnaparkhi > <shripad.ratnaparkhi@gmail.com> 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@gmail.com> 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@vger.kernel.org >> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Apr 07, 2013 at 07:41:04AM +0530, Shripad Ratnaparkhi wrote:> 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.https://btrfs.wiki.kernel.org/index.php/FAQ#What.27s_the_difference_between_btrfsck_and_fsck.btrfs btrfsck is not supposed to be run at boot time, therefore fsck.btrfs is only a stub. david -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Reasonably Related Threads
- btrfsck: extent-tree.c:2549: btrfs_reserve_extent: Assertion `!(ret)' failed.
- Can't remove empty directory after kernel panic, no errors in dmesg
- Filesystem "somewhat" destroyed - need help for recovery/fixing
- How to use Net::SSH
- Handling SOAP XML request and Response