linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>
To: Gard Vaaler <gardv@megacandy.net>
Cc: Nikolay Borisov <nborisov@suse.com>, linux-btrfs@vger.kernel.org
Subject: Re: Unrecoverable corruption after loss of cache
Date: Wed, 4 Dec 2019 21:45:44 -0500	[thread overview]
Message-ID: <20191205024544.GW22121@hungrycats.org> (raw)
In-Reply-To: <E5ED2688-A506-4D11-8D01-27BD7C366894@megacandy.net>

[-- Attachment #1: Type: text/plain, Size: 1481 bytes --]

On Mon, Dec 02, 2019 at 10:27:49PM +0100, Gard Vaaler wrote:
> > 1. des. 2019 kl. 19:51 skrev Nikolay Borisov <nborisov@suse.com>:
> > On 1.12.19 г. 19:27 ч., Gard Vaaler wrote:
> >> Trying to recover a filesystem that was corrupted by losing writes due to a failing caching device, I get the following error:
> >>> ERROR: child eb corrupted: parent bytenr=2529690976256 item=0 parent level=2 child level=0
> >> 
> >> Trying to zero the journal or reinitialising the extent tree yields the same error. Is there any way to recover the filesystem? Relevant logs attached.
> > 
> > Provide more information about your storage stack.
> 
> 
> Nothing special: SATA disks with (now-detached) SATA SSDs.

Is it a pair of 2x (bcache-on-disk) in raid1?  Did both cache devices
fail?  Were they configured as writeback cache?  Does the drive firmware
have bugs that affect either btrfs or bcache?

If the caches are independent (no shared caches or disks), and you
had only one cache device failure, and the filesystem is btrfs raid1,
then the non-failing cache should be OK, and can be used to recover the
contents of failed device.  You'll need at least one pair of cache and
disk to be up and running.

If any of those conditions are false then it's probably toast.  btrfs
will reject a filesystem missing just one write--a filesystem missing
thousands or millions of writes due to a writeback cache failure is
going to be data soup.



> -- 
> Gard
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

  reply	other threads:[~2019-12-05  2:45 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-01 17:27 Unrecoverable corruption after loss of cache Gard Vaaler
2019-12-01 18:51 ` Nikolay Borisov
2019-12-02 21:27   ` Gard Vaaler
2019-12-05  2:45     ` Zygo Blaxell [this message]
2019-12-04 15:50 ` Gard Vaaler
2019-12-04 19:08   ` Chris Murphy
2019-12-04 20:21     ` Gard Vaaler
     [not found]     ` <B154F1B0-C80A-4E7E-B105-B0E654279E28@megacandy.net>
2019-12-04 21:09       ` Chris Murphy
2019-12-05  0:34         ` Gard Vaaler
2019-12-05  1:26           ` Chris Murphy

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=20191205024544.GW22121@hungrycats.org \
    --to=ce3g8jdj@umail.furryterror.org \
    --cc=gardv@megacandy.net \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=nborisov@suse.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).