Linux-BTRFS Archive on
 help / color / Atom feed
From: Chris Murphy <>
To: Gard Vaaler <>
Cc: Chris Murphy <>,
	Btrfs BTRFS <>
Subject: Re: Unrecoverable corruption after loss of cache
Date: Wed, 4 Dec 2019 18:26:59 -0700
Message-ID: <> (raw)
In-Reply-To: <>

On Wed, Dec 4, 2019 at 5:34 PM Gard Vaaler <> wrote:
> > 4. des. 2019 kl. 22:09 skrev Chris Murphy <>:
> > There's a decent chance this is the cause of the problem. That kernel
> > does not have the fix for this bug:
> >
> >
> >
> > As far as I'm aware the corruption isn't fixable. You might still be
> > able to mount the file system ro to get data out; if not then decent
> > chance you can extract data with btrfs restore, which is an offline
> > scraping tool, but it is a bit tedious to use.
> >
> That was my first thought too, but it seems too coincidental that I should happen across this bug at the same instant as my cache device failing. btrfs-restore doesn't like my filesystem either:

You know, I totally glossed over the cache device failing part of the
very first message 8-\ But yeah it would seem like the cache device
dropped a bunch of metadata. Really a lot more than I'd expect from
the aforementioned kernel bug. So chances are your suspicion is spot

> > [liveuser@localhost-live btrfs-progs-5.4]$ sudo ./btrfs restore -Divvv /dev/bcache0 /mnt
> > This is a dry-run, no files are going to be restored
> > parent transid verify failed on 3719816445952 wanted 317513 found 313040
> > parent transid verify failed on 3719816445952 wanted 317513 found 308297
> > parent transid verify failed on 3719816445952 wanted 317513 found 313040
> > Ignoring transid failure
> > leaf parent key incorrect 3719816445952
> > Error searching -1

You might have to to try a lot of the btrfs-find-root block addresses
(start with highest transid working down) with btrfs restore -t option
to force it to use older roots. Maybe one of them will be intact. It's
also possible to isolate to a subvolume, if you have home on a
subvolume for example.

Unfortunately btrfs restore isn't a simple scraper, it doesn't
iterate. You have to do that part. It is tedious.

Chris Murphy

      reply index

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-01 17:27 Gard Vaaler
2019-12-01 18:51 ` Nikolay Borisov
2019-12-02 21:27   ` Gard Vaaler
2019-12-05  2:45     ` Zygo Blaxell
2019-12-04 15:50 ` Gard Vaaler
2019-12-04 19:08   ` Chris Murphy
2019-12-04 20:21     ` Gard Vaaler
     [not found]     ` <>
2019-12-04 21:09       ` Chris Murphy
2019-12-05  0:34         ` Gard Vaaler
2019-12-05  1:26           ` Chris Murphy [this message]

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 \
    --in-reply-to='' \ \ \ \

* 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

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone