Linux-BTRFS Archive on lore.kernel.org
 help / color / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Illia Bobyr <illia.bobyr@gmail.com>, linux-btrfs@vger.kernel.org
Subject: Re: "parent transid verify failed" and mount usebackuproot does not seem to work
Date: Wed, 1 Jul 2020 09:36:51 +0800
Message-ID: <45900280-c948-05d2-2cd8-67480baaedae@gmx.com> (raw)
In-Reply-To: <CAHzXa9XOa1bppK44pKrqbSq50Xdsm63D_698gvo2G-JDWrNeLg@mail.gmail.com>

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



On 2020/7/1 上午3:41, Illia Bobyr wrote:
> Hi,
> 
> I have a btrfs with bcache setup that failed during a boot yesterday.
> There is one SSD with bcache that is used as a cache for 3 btrfs HDDs.
> 
> Reading through a number of discussions, I've decided to ask for advice here.
> Should I be running "btrfs check --recover"?
> 
> The last message in the dmesg log is this one:
> 
> Btrfs loaded, crc32c=crc32c-intel
> BTRFS: device label root devid 3 transid 138434 /dev/bcache2 scanned
> by btrfs (341)
> BTRFS: device label root devid 2 transid 138434 /dev/bcache1 scanned
> by btrfs (341)
> BTRFS: device label root devid 1 transid 138434 /dev/bcache0 scanned
> by btrfs (341)
> BTRFS info (device bcache0): disk space caching is enabled
> BTRFS info (device bcache0): has skinny extents
> BTRFS error (device bcache0): parent transid verify failed on
> 16984159518720 wanted 138414 found 138207
> BTRFS error (device bcache0): parent transid verify failed on
> 16984159518720 wanted 138414 found 138207
> BTRFS error (device bcache0): open_ctree failed

Looks like some tree blocks not written back correctly.

Considering we don't have known write back related bugs with 5.6, I
guess bcache may be involved again?

> 
> Trying to mount it in the recovery mode does not seem to work:
> 
> (initramfs) mount -t btrfs -o ro,usebackuproot /dev/bcache0 /mnt
> BTRFS info (device bcache1): trying to use backup root at mount time
> BTRFS info (device bcache1): disk space caching is enabled
> BTRFS info (device bcache1): has skinny extents
> BTRFS error (device bcache1): parent transid verify failed on
> 16984159518720 wanted 138414 found 138207
> BTRFS error (device bcache1): parent transid verify failed on
> 16984159518720 wanted 138414 found 138207
> BTRFS error (device bcache1): parent transid verify failed on
> 16984173199360 wanted 138433 found 138195
> BTRFS error (device bcache1): parent transid verify failed on
> 16984173199360 wanted 138433 found 138195
> BTRFS warning (device bcache1): failed to read tree root
> BTRFS error (device bcache1): parent transid verify failed on
> 16984171298816 wanted 138431 found 131157
> BTRFS error (device bcache1): parent transid verify failed on
> 16984171298816 wanted 138431 found 131157
> BTRFS warning (device bcache1): failed to read tree root
> BTRFS critical (device bcache1): corrupt leaf: block=16984183013376
> slot=36 extent bytenr=11447166291968 len=262144 invalid generation,
> have 138434 expect (0, 138433]
> BTRFS error (device bcache1): block=16984183013376 read time tree
> block corruption detected
> BTRFS critical (device bcache1): corrupt leaf: block=16984183013376
> slot=36 extent bytenr=11447166291968 len=262144 invalid generation,
> have 138434 expect (0, 138433]
> BTRFS error (device bcache1): block=16984183013376 read time tree
> block corruption detected
> BTRFS warning (device bcache1): failed to read tree root
> BUG: kernel NULL pointer dereference, address: 000000000000001f
> #PF: supervisor read access in kernel mode
> 
> <a stack trace follows>
> 
> (initramfs) btrfs --version
> btrfs-progs v5.4.1
> 
> (initramfs) uname -a
> Linux (none) 5.6.11-050611-generic #202005061022 SMP Wed May 6 10:27:04
> UTC 2020 x86_64 GNU/Linux
> 
> (initramfs) btrfs fi show
> Label: 'root' uuid: 0a3d051b-72ef-4a5d-8a48-eb0dbb960b56
>         Total devices 3 FS bytes used 6.55TiB
>         devid    1 size 3.64TiB used 1.62TiB path /dev/bcache1
>         devid    2 size 7.28TiB used 5.21TiB path /dev/bcache0
>         devid    3 size 12.73TiB used 6.80TiB path /dev/bcache2
> 
> I have tried booting using a live ISO with 5.8.0 kernel and btrfs v5.6.1
> from http://defender.exton.net/.
> After booting tried mounting the bcache using the same command as above.
> The only message in the console was "Killed".
> /dev/kmsg on the other hand lists messages very similar to the ones I've
> seen in the initramfs environment: https://pastebin.com/Vhy072Mx

It looks like there is a chance to recover, as there is a rootbackup
with newer generation.

While tree-checker is rejecting the newer generation one.

The kernel panic is caused by some corner error handling with root
backups cleanups.
We need to fix it anyway.

In this case, I guess "btrfs ins dump-super -fFa" output would help to
show if it's possible to recover.

Anyway, something looks strange.

The backup roots have a newer generation while the super block is still
old doesn't look correct at all.

Thanks,
Qu
> 
> P.S. Please CC me, as I am not subscribed.
> 
> Thank you,
> Illia Bobyr
> 


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

  reply index

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-30 19:41 Illia Bobyr
2020-07-01  1:36 ` Qu Wenruo [this message]
2020-07-01 10:16   ` Illia Bobyr
2020-07-01 10:48     ` Qu Wenruo
2020-07-01 21:36       ` Illia Bobyr
2020-07-01 23:50         ` Qu Wenruo
  -- strict thread matches above, loose matches on Subject: below --
2020-06-30 19:26 Illia Bobyr
2020-06-30 19:55 ` Lukas Straub
2020-06-30  4:24 Illia Bobyr

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45900280-c948-05d2-2cd8-67480baaedae@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=illia.bobyr@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-BTRFS Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-btrfs/0 linux-btrfs/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-btrfs linux-btrfs/ https://lore.kernel.org/linux-btrfs \
		linux-btrfs@vger.kernel.org
	public-inbox-index linux-btrfs

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-btrfs


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git