Linux-BTRFS Archive on
 help / color / Atom feed
From: Qu Wenruo <>
To: Alexander Wetzel <>,,
Subject: Re: [BUG] BTRFS critical corrupt leaf - bisected to 496245cac57e
Date: Sun, 14 Jul 2019 20:51:04 +0800
Message-ID: <> (raw)
In-Reply-To: <>

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

>> I totally understand that the solution I'm going to provide sounds
>> aweful, but I'd recommend to use a newer enough kernel but without that
>> check, to copy all the data to another btrfs fs.
>>  > It could be more safe than waiting for a btrfs check to repair it.
> No problem for me. This report here was created for science only:-)

Thank you for your report!

It really reminds us how badly we did in the past, and gives me some
more hint on how to enhance the tree-checker to report more corruptions!

> I just wanted to your attention prior to destroying the broken FS and
> shredding potential useful data useful to track down what went wrong.
> With that now concluded I'll just do that!
> But maybe one additional remark: The snapshots transferred via btrfs
> send/receive to another PC are working fine on a system using a 5.2
> kernel.

Depends on how you send.
If you are sending the subvolume alone, (without -p or -c), it only
contains data (obviously), inode mode (regular, dir, block ...)
timestamps, filenames.

No internal structures like transid/sequence included, thus send/receive
will remove the corrupted internal structures, and since the destination
is 5.2 kernel, it will recreate them using correct values.

> Since the "moved" subvolume also does not have the block
> 8645398528 I assume I don't really have to copy the files but restoring
> the subvolume with btrfs receive on a new btrfs image will also get rid
> of the errors.

No need to bother that intermediate number at all. It's completely tree
block bytenr.
You don't need to worry about tree blocks, they're just an internal
method to restore things like filenames mentioned above.

As long as the important part is the received correctly, there is
nothing you'd ever need to bother, as they are all *internal* used data
structures, only kernel and developers need to care (and in this case,
receive side kernel will handle it, even developer don't need to care).


> Thanks for your time, the incredible fast feedback and your help,
> Alexander

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

  reply index

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-13 20:48 Alexander Wetzel
2019-07-14  1:30 ` Qu Wenruo
2019-07-14  9:25   ` Alexander Wetzel
2019-07-14  9:49     ` Qu Wenruo
2019-07-14 12:07       ` Alexander Wetzel
2019-07-14 12:51         ` Qu Wenruo [this message]
2019-07-14 15:40       ` Chris Murphy
2019-07-15  1:07         ` Qu Wenruo

Reply instructions:

You may reply publically 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:

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

  git send-email \ \ \ \ \ \

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

Linux-BTRFS Archive on

Archives are clonable:
	git clone --mirror 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/ \
	public-inbox-index linux-btrfs

Newsgroup available over NNTP:

AGPL code for this site: git clone public-inbox