btrfsck failes
Dear BTRFS developers, thanks for providing a filesystem with which I am happy so far! Currently btrfsck failes to repair my partition, I get the output: [root@ho-think bholger]# btrfsck --repair /dev/sda5 [...] leaf parent key incorrect 600846336 parent transid verify failed on 600846336 wanted 23460 found 23463 Ignoring transid failure leaf parent key incorrect 600846336 bad block 600395776 bad block 600518656 bad block 600547328 leaf parent key incorrect 600846336 bad block 600846336 bad block 601710592 bad block 603197440 Ignoring transid failure parent transid verify failed on 601710592 wanted 23460 found 23463 Ignoring transid failure parent transid verify failed on 602529792 wanted 23460 found 23463 Ignoring transid failure btrfsck: disk-io.c:155: readahead_tree_block: Assertion `!(ret)' failed. Aborted (core dumped) >From dmesg I get the additional information: [ 629.447677] btrfs: device fsid f6907d81-f46f-4911-8600-858e8b6bd1a0 devid 1 transid 23462 /dev/sda5 [ 629.671835] systemd-journald[182]: Vacuuming done, freed 0 bytes [ 629.843055] systemd-journald[182]: Failed to write entry (26 items, 416256620 bytes) despite vacuuming, ignoring: Argument list too long I am running Arch linux with btrfs-progs-3.12-1 and [root@ho-think bholger]# uname -r 3.12.7-2-ARCH The filesystem got some problems today while being mounted, it got mounted read-only due to an error, but I still had access to my data. I had to unmount it to run btrfsck, but because it fails to repair my disk, I cannot mount it any more. Any advice? Holger -- 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
Re: btrfsck failes
Oh and if I do mount -o recovery /dev/sda5 /some/path/ then I get the following in dmesg: [ 1449.171259] btrfs: device fsid f6907d81-f46f-4911-8600-858e8b6bd1a0 devid 1 transid 23462 /dev/sda5 [ 1449.171635] btrfs: enabling auto recovery [ 1449.171638] btrfs: disk space caching is enabled [ 1451.848339] btrfs: space cache generation (23463) does not match inode (23461) [ 1451.848360] BTRFS error (device sda5): failed to load free space cache for block group 1103101952 [ 1451.959865] parent transid verify failed on 601710592 wanted 23460 found 23463 [ 1451.969678] parent transid verify failed on 601710592 wanted 23460 found 23463 [ 1452.461075] btrfs: space cache generation (23463) does not match inode (23461) [ 1452.461094] BTRFS error (device sda5): failed to load free space cache for block group 2176843776 [ 1456.915205] parent transid verify failed on 603377664 wanted 23460 found 23463 [ 1456.925074] parent transid verify failed on 603377664 wanted 23460 found 23463 [ 1456.925827] BTRFS error (device sda5) in open_ctree:2847: errno=-5 IO failure (Failed to recover log tree) [ 1456.971476] btrfs: open_ctree failed On Mon, Jan 13, 2014 at 11:58 PM, Holger Brandsmeier wrote: > Dear BTRFS developers, > > thanks for providing a filesystem with which I am happy so far! > > Currently btrfsck failes to repair my partition, I get the output: > > [root@ho-think bholger]# btrfsck --repair /dev/sda5 > [...] > leaf parent key incorrect 600846336 > parent transid verify failed on 600846336 wanted 23460 found 23463 > Ignoring transid failure > leaf parent key incorrect 600846336 > bad block 600395776 > bad block 600518656 > bad block 600547328 > leaf parent key incorrect 600846336 > bad block 600846336 > bad block 601710592 > bad block 603197440 > Ignoring transid failure > parent transid verify failed on 601710592 wanted 23460 found 23463 > Ignoring transid failure > parent transid verify failed on 602529792 wanted 23460 found 23463 > Ignoring transid failure > btrfsck: disk-io.c:155: readahead_tree_block: Assertion `!(ret)' failed. > Aborted (core dumped) > > > From dmesg I get the additional information: > > [ 629.447677] btrfs: device fsid f6907d81-f46f-4911-8600-858e8b6bd1a0 > devid 1 transid 23462 /dev/sda5 > [ 629.671835] systemd-journald[182]: Vacuuming done, freed 0 bytes > [ 629.843055] systemd-journald[182]: Failed to write entry (26 items, > 416256620 bytes) despite vacuuming, ignoring: Argument list too long > > I am running Arch linux with btrfs-progs-3.12-1 and > [root@ho-think bholger]# uname -r > 3.12.7-2-ARCH > > The filesystem got some problems today while being mounted, it got > mounted read-only due to an error, but I still had access to my data. > I had to unmount it to run btrfsck, but because it fails to repair my > disk, I cannot mount it any more. > > Any advice? > Holger -- 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
Re: btrfsck failes
I modified the code (now I am using the git repository) of disk-io.c
to include the debug output
if(ret) {
printf("btrfs_map_block(bytenr=%u, length=%u) has code %d\n",
bytenr, length, ret);
}
before the assertion throws, and I get:
btrfs_map_block(bytenr=2684354560, length=4096) has code -2
i.e. the error is ENOENT.
-Holger
On Tue, Jan 14, 2014 at 12:15 AM, Holger Brandsmeier
wrote:
> Oh and if I do
> mount -o recovery /dev/sda5 /some/path/
>
> then I get the following in dmesg:
>
> [ 1449.171259] btrfs: device fsid f6907d81-f46f-4911-8600-858e8b6bd1a0
> devid 1 transid 23462 /dev/sda5
> [ 1449.171635] btrfs: enabling auto recovery
> [ 1449.171638] btrfs: disk space caching is enabled
> [ 1451.848339] btrfs: space cache generation (23463) does not match
> inode (23461)
> [ 1451.848360] BTRFS error (device sda5): failed to load free space
> cache for block group 1103101952
> [ 1451.959865] parent transid verify failed on 601710592 wanted 23460
> found 23463
> [ 1451.969678] parent transid verify failed on 601710592 wanted 23460
> found 23463
> [ 1452.461075] btrfs: space cache generation (23463) does not match
> inode (23461)
> [ 1452.461094] BTRFS error (device sda5): failed to load free space
> cache for block group 2176843776
> [ 1456.915205] parent transid verify failed on 603377664 wanted 23460
> found 23463
> [ 1456.925074] parent transid verify failed on 603377664 wanted 23460
> found 23463
> [ 1456.925827] BTRFS error (device sda5) in open_ctree:2847: errno=-5
> IO failure (Failed to recover log tree)
> [ 1456.971476] btrfs: open_ctree failed
>
>
> On Mon, Jan 13, 2014 at 11:58 PM, Holger Brandsmeier
> wrote:
>> Dear BTRFS developers,
>>
>> thanks for providing a filesystem with which I am happy so far!
>>
>> Currently btrfsck failes to repair my partition, I get the output:
>>
>> [root@ho-think bholger]# btrfsck --repair /dev/sda5
>> [...]
>> leaf parent key incorrect 600846336
>> parent transid verify failed on 600846336 wanted 23460 found 23463
>> Ignoring transid failure
>> leaf parent key incorrect 600846336
>> bad block 600395776
>> bad block 600518656
>> bad block 600547328
>> leaf parent key incorrect 600846336
>> bad block 600846336
>> bad block 601710592
>> bad block 603197440
>> Ignoring transid failure
>> parent transid verify failed on 601710592 wanted 23460 found 23463
>> Ignoring transid failure
>> parent transid verify failed on 602529792 wanted 23460 found 23463
>> Ignoring transid failure
>> btrfsck: disk-io.c:155: readahead_tree_block: Assertion `!(ret)' failed.
>> Aborted (core dumped)
>>
>>
>> From dmesg I get the additional information:
>>
>> [ 629.447677] btrfs: device fsid f6907d81-f46f-4911-8600-858e8b6bd1a0
>> devid 1 transid 23462 /dev/sda5
>> [ 629.671835] systemd-journald[182]: Vacuuming done, freed 0 bytes
>> [ 629.843055] systemd-journald[182]: Failed to write entry (26 items,
>> 416256620 bytes) despite vacuuming, ignoring: Argument list too long
>>
>> I am running Arch linux with btrfs-progs-3.12-1 and
>> [root@ho-think bholger]# uname -r
>> 3.12.7-2-ARCH
>>
>> The filesystem got some problems today while being mounted, it got
>> mounted read-only due to an error, but I still had access to my data.
>> I had to unmount it to run btrfsck, but because it fails to repair my
>> disk, I cannot mount it any more.
>>
>> Any advice?
>> Holger
--
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
Fwd: btrfsck failes
+linux-btrfs@vger.kernel.org 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 wrote: > > On Jan 14, 2014, at 4:24 PM, Holger Brandsmeier wrote: > >> Dear Chris, >> >> as requested: >> >> # btrfs fi show >> Label: none uuid: 267f069c-11da-4d2a-88fa-00cab4e28149 >>Total devices 1 FS bytes used 12.68GiB >>devid1 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 >>devid1 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@vger.kernel.org/msg27613.html > > > > 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 -- 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
Re: btrfsck failes
I agree to Marc, I created a small patch to `cmds-check.c` (see
attachments). It displays a warning message for 10 seconds if the
repair option is enabled. If you think this is a good idea, can
someone apply this patch?
I am going to roll in my backup soon. Is there anything more that I
should give you as a feedback? I did file one bug:
https://bugzilla.kernel.org/show_bug.cgi?id=68771
On Thu, Jan 16, 2014 at 1:19 PM, Marc MERLIN wrote:
> On Wed, Jan 15, 2014 at 10:16:13AM -0700, Chris Murphy wrote:
>>
>> On Jan 15, 2014, at 9:15 AM, Mitch Harder
>> wrote:
>>
>> > On Mon, Jan 13, 2014 at 6:37 PM, Chris Murphy
>> > wrote:
>> >>
>> >> On Jan 13, 2014, at 3:58 PM, Holger Brandsmeier
>> >> wrote:
>> >>>
>> >>> Currently btrfsck failes to repair my partition, I get the output:
>> >>>
>> >>> [root@ho-think bholger]# btrfsck --repair /dev/sda5
>> >>
>> >> This is almost the last resort and you probably should be posting to the
>> >> list before using repair.
>> >>
>> >>
>> >
>> > This is like saying:
>> >
>> > "Yes, btrfs does now have a working btrfsck, but only for the select
>> > few who manage to get through on the mailing list for support."
>> >
>> > I'd like to think that's not the case.
>>
>> Yet that's exactly what the wiki suggests: "If you have a broken filesystem,
>> it is probably better to use btrfsck with advice from one of the btrfs
>> developers, just in case something goes wrong. (But even if it does go badly
>> wrong, you've still got your backups, right?)"
>>
>> I think it's understandably annoying that the repair tool could make things
>> worse rather than fail gracefully, because restoring from backups is
>> tedious. But the only way it gets better is if people break both the file
>> system and the repair tools in ways the devs can't possibly predict.
>
> I hate to be a broken record :) but telling people they should read/have
> read a wiki when they are in the middle of fixing a filesystem is not
> the right way to go.
> On my laptop while travelling, it would even be my only way to boot and
> maybe I can't get to the internet until my FS is fixed (maybe, maybe
> not, but you get the idea).
>
> My main point again (sorry) is still that the man page and usage info of
> btrfsck
> should really warn users "this is likely NOT what you want to run,
> please read the manpage, or HOWTO in /usr/share/doc/ with details about
> mount recovery and other things to try first".
>
> Think of it as a good thing, it means more btrfs users, and they are
> used to working a certain way. It's for btrfs to adapt to how they're
> used to working when possible.
>
> Marc
> --
> "A mouse is a device used to point at the xterm you want to type in" - A.S.R.
> Microsoft is to operating systems
> what McDonalds is to gourmet
> cooking
> Home page: http://marc.merlins.org/ | PGP
> 1024R/763BE901
> --
> 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
--- cmds-check.c
+++ cmds-check.c
@@ -6427,6 +6427,15 @@ int cmd_check(int argc, char **argv)
if (argc != 1)
usage(cmd_check_usage);
+ if (repair != 0) {
+ printf("\nWARNING: you enabled repair mode, this option could make "
+ "matters worse for your data. It is recommended to check with the "
+ "linux-btrfs@vger.kernel.org mailing list before you proceed.\n");
+ printf("Sleeping for 10 seconds to give you time to consider..."
+ " hit ctrl+c if you changed your mind.\n");
+ sleep(10);
+ }
+
radix_tree_init();
cache_tree_init(&root_cache);
