unmountable filesystem: open_ctree failed

unmountable filesystem: open_ctree failed

[Christoph Heinrich]

Hello,



my hard drive can't be mounted anymore.

Two days ago the drive was very slow (<1kb/s read and write, but I didn't find any errors anywhere).

However after unplugging and plugging in again, everything seemed normal again, so I don't know if that's related.



When trying to mount it today I get that error:



mount: /mnt: wrong fs type, bad option, bad superblock on /dev/sdb, missing codepage or helper program, or other error.



Mounting without -o results in dmesg:



[14479.650956] BTRFS info (device sdb): disk space caching is enabled

[14479.650963] BTRFS info (device sdb): has skinny extents

[14499.742007] BTRFS error (device sdb): parent transid verify failed on 3437913341952 wanted 7041 found 6628

[14499.753076] BTRFS error (device sdb): parent transid verify failed on 3437913341952 wanted 7041 found 6628

[14499.753089] BTRFS error (device sdb): failed to read block groups: -5

[14499.816157] BTRFS error (device sdb): open_ctree failed



I already tried mounting with usebackuproot,nospace_cache,clear_cache, but that resulted in the same error messages as before.



When running btrfs check I get the output:

parent transid verify failed on 3437913341952 wanted 7041 found 6628

parent transid verify failed on 3437913341952 wanted 7041 found 6628

parent transid verify failed on 3437913341952 wanted 7041 found 6628

Ignoring transid failure

ERROR: child eb corrupted: parent bytenr=3437941538816 item=123 parent level=2 child level=0

ERROR: failed to read block groups: Input/output error

ERROR: cannot open file system



 From what I've read so far, running btrfs-zero-log or btrfs check --repair may help,
but it may also do more damage then good, so I'd rather ask then make the situation worse then it already is.



kernel 5.6.11

btrfs-progs 5.6



Regards,

Christoph

Re: unmountable filesystem: open_ctree failed

[Chris Murphy]

Hi,

On Sun, May 10, 2020 at 10:52 AM Christoph Heinrich <chheinml@gmail.com> wrote:
>
> Hello,
>
>
>
> my hard drive can't be mounted anymore.
>
> Two days ago the drive was very slow (<1kb/s read and write, but I didn't find any errors anywhere).
>
> However after unplugging and plugging in again, everything seemed normal again, so I don't know if that's related.

If you were using 5.6.x at the time of this, the tree checker should
stop things on write if there's a problem, before there's corruption.
It's possible there's previously existing corruption.


>
> When trying to mount it today I get that error:
>
>
>
> mount: /mnt: wrong fs type, bad option, bad superblock on /dev/sdb, missing codepage or helper program, or other error.
>
>
>
> Mounting without -o results in dmesg:
>
>
>
> [14479.650956] BTRFS info (device sdb): disk space caching is enabled
>
> [14479.650963] BTRFS info (device sdb): has skinny extents
>
> [14499.742007] BTRFS error (device sdb): parent transid verify failed on 3437913341952 wanted 7041 found 6628
>
> [14499.753076] BTRFS error (device sdb): parent transid verify failed on 3437913341952 wanted 7041 found 6628
>
> [14499.753089] BTRFS error (device sdb): failed to read block groups: -5
>
> [14499.816157] BTRFS error (device sdb): open_ctree failed
>
>
>
> I already tried mounting with usebackuproot,nospace_cache,clear_cache, but that resulted in the same error messages as before.
>
>
>
> When running btrfs check I get the output:
>
> parent transid verify failed on 3437913341952 wanted 7041 found 6628
>
> parent transid verify failed on 3437913341952 wanted 7041 found 6628
>
> parent transid verify failed on 3437913341952 wanted 7041 found 6628
>
> Ignoring transid failure
>
> ERROR: child eb corrupted: parent bytenr=3437941538816 item=123 parent level=2 child level=0
>
> ERROR: failed to read block groups: Input/output error
>
> ERROR: cannot open file system
>
>
>
>  From what I've read so far, running btrfs-zero-log or btrfs check --repair may help,
> but it may also do more damage then good, so I'd rather ask then make the situation worse then it already is.

What do you get for:

# btrfs insp dump-s /dev/
# btrfs insp dump-t -b 3437913341952 /dev/
# btrfs-find-root /dev/

Those are all read only commands and make no changes to the file
system. Also, what are the mount options for this file system in
/etc/fstab?

> kernel 5.6.11
>
> btrfs-progs 5.6

Was this file system ever written to by kernels 5.2.0 - 5.2.14? There
was a pretty nasty bug in that range that might be related, but the
transid want have difference is bigger than I'd expect for that bug.


-- 
Chris Murphy

Re: unmountable filesystem: open_ctree failed

[Qu Wenruo]

[-- Attachment #1.1: Type: text/plain, Size: 3514 bytes --]



On 2020/5/11 上午12:51, Christoph Heinrich wrote:
> Hello,
> 
> 
> 
> my hard drive can't be mounted anymore.
> 
> Two days ago the drive was very slow (<1kb/s read and write, but I
> didn't find any errors anywhere).

Something looks tricky, and SMART reports no error?

> 
> However after unplugging and plugging in again, everything seemed normal
> again, so I don't know if that's related.
> 
> 
> 
> When trying to mount it today I get that error:
> 
> 
> 
> mount: /mnt: wrong fs type, bad option, bad superblock on /dev/sdb,
> missing codepage or helper program, or other error.
> 
> 
> 
> Mounting without -o results in dmesg:
> 
> 
> 
> [14479.650956] BTRFS info (device sdb): disk space caching is enabled
> 
> [14479.650963] BTRFS info (device sdb): has skinny extents
> 
> [14499.742007] BTRFS error (device sdb): parent transid verify failed on
> 3437913341952 wanted 7041 found 6628
> 
> [14499.753076] BTRFS error (device sdb): parent transid verify failed on
> 3437913341952 wanted 7041 found 6628

Either btrfs or the disk failed to write certain data onto disk.
This breaks the COW requirement and corrupted the extent tree.

There is a pending patch to skip extent tree read, allow user to do RO
mount and salvage data, but that's not merged for a long long time.

> 
> [14499.753089] BTRFS error (device sdb): failed to read block groups: -5
> 
> [14499.816157] BTRFS error (device sdb): open_ctree failed
> 
> 
> 
> I already tried mounting with usebackuproot,nospace_cache,clear_cache,
> but that resulted in the same error messages as before.

Existing rescue options won't help.

In this case, your only hope would be salvaging data.
Other than that pending patch, btrfs-restore is here.

> 
> 
> 
> When running btrfs check I get the output:
> 
> parent transid verify failed on 3437913341952 wanted 7041 found 6628
> 
> parent transid verify failed on 3437913341952 wanted 7041 found 6628
> 
> parent transid verify failed on 3437913341952 wanted 7041 found 6628
> 
> Ignoring transid failure
> 
> ERROR: child eb corrupted: parent bytenr=3437941538816 item=123 parent
> level=2 child level=0

Yeah, some write didn't reach disk.
This means either the disk is reporting false FLUSH/FUA result (return
before all data reach disk), or btrfs has something wrong.

If you have run btrfs kernel between 5.2.15~5.3.0, it's possible that
one kernel regression caused such problem.

> 
> ERROR: failed to read block groups: Input/output error
> 
> ERROR: cannot open file system
> 
> 
> 
> From what I've read so far, running btrfs-zero-log or btrfs check
> --repair may help,

--repair won't help afaik.
But --init-exten-tree may help.

The problem is, normally we use btrfs check to do a basic evaluation on
how damaged the fs is (mostly to ensure fs trees are all OK).

But in your case, btrfs check failed to continue, thus we don't now if
that transid error is the only error.

So if you want to salvage data, either go btrfs-restore or compile that
out-of-tree patch.
If you don't care the data, but want to take an adventure, try btrfs
check --init-extent-tree, which can screw up the fs even more, or may
save your fs to completely fine status.

Thanks,
Qu

> but it may also do more damage then good, so I'd rather ask then make
> the situation worse then it already is.
> 
> 
> 
> kernel 5.6.11
> 
> btrfs-progs 5.6
> 
> 
> 
> Regards,
> 
> Christoph


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]