Re: btrfsck failes

Re: btrfsck failes

[Chris Murphy]

On Jan 14, 2014, at 4:24 PM, Holger Brandsmeier <brandsmeier@gmail.com> wrote:

> Dear Chris,
> 
> as requested:
> 
> # btrfs fi show
> Label: none  uuid: 267f069c-11da-4d2a-88fa-00cab4e28149
>        Total devices 1 FS bytes used 12.68GiB
>        devid    1 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
>        devid    1 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

Fwd: btrfsck failes

[Holger Brandsmeier]

+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 <lists@colorremedies.com> wrote:
>
> On Jan 14, 2014, at 4:24 PM, Holger Brandsmeier <brandsmeier@gmail.com> wrote:
>
>> Dear Chris,
>>
>> as requested:
>>
>> # btrfs fi show
>> Label: none  uuid: 267f069c-11da-4d2a-88fa-00cab4e28149
>>        Total devices 1 FS bytes used 12.68GiB
>>        devid    1 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
>>        devid    1 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fwd: btrfsck failes

[Marc MERLIN]

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.

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

Re: btrfsck failes

[Chris Murphy]

On Jan 15, 2014, at 8:15 AM, Marc MERLIN <marc@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