All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicholas D Steeves <nsteeves@gmail.com>
To: Chris Murphy <lists@colorremedies.com>,
	efkf@firemail.cc, Duncan <1i5t5.duncan@cox.net>
Cc: Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: Tried to replace a drive in a raid 1 and all hell broke loose
Date: Sat, 28 May 2022 16:20:59 -0400	[thread overview]
Message-ID: <87tu99h0ic.fsf@DigitalMercury.freeddns.org> (raw)
In-Reply-To: <CAJCQCtT_PjKprryxHwsyn3qXc06qFFmnMR48CxZuvav8aQUOQQ@mail.gmail.com>

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

Hi Chris, Efkf, Duncan, and anyone else reading this,

Chris Murphy <lists@colorremedies.com> writes:

>>#btrfs fi df /mnt/sd/
>>Data, RAID1: total=772.00GiB, used=771.22GiB
>>Data, single: total=1.00GiB, used=2.25MiB
>>System, RAID1: total=32.00MiB, used=96.00KiB
>>System, single: total=32.00MiB, used=48.00KiB
>>Metadata, RAID1: total=3.00GiB, used=1.54GiB
>>Metadata, single: total=1.00GiB, used=0.00B
>
> This is not good. Some of the data and some of the metadata
> (specifically system profile which is the chunk tree) is only
> available on one drive and I can't tell from this if it's on a drive
> that is missing or is spewing errors. Anything that has a single copy
> that's also damaged, cannot be recovered. Unfortunately this file
> system is not completely raid1 and that's likely one source of the
> problem. The chunk tree is really critical so if any part of it is bad
> and not redundant (no good copy) the file system is not likely
> repairable. Get the data out as best you can. If rescue=all mount
> option doesn't work, the next opportunity is btrfs restore, but it too
> depends on the chunk tree being intact. There is a 'btrfs restore
> chunk-tree' option that will scan all the drives looking for plausible
> fragments of the chunk tree to try and recover it but it takes a long
> time (hours).
>
> 48KiB of chunk tree, if it's corrupt, is quite a lot and might prevent
> quite a lot of recovery. Some older kernels would create single
> profile chunks when a raid1 file system was mounted in degraded,rw
> mode with a missing device. This happens silently. And then when the
> raid1 is back to full strength again, there's no automatic conversion
> or even a warning by the kernel that this critical metadata isn't
> redundant still. The burden right now is unfortunately on the user to
> identify this reduction in redundancy and make sure to do a filtered
> balance to convert the single chunks into raid1 chunks.
>

I reported this issue "Wed, 02 Mar 2016 20:25:46 -0500" with Subject
"incomplete conversion to RAID1?", and it now looks that there's
evidence that this bug isn't harmless after all.

Efkf, would you please confirm if the filesystem was created with Linux
and btrfs-progs 5.10.x? (please keep me in CC)

If anyone knows if this issue was fixed for 5.15, please share the good
news!


Regards,
Nicholas

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

  parent reply	other threads:[~2022-05-28 20:21 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-23 17:21 Tried to replace a drive in a raid 1 and all hell broke loose efkf
     [not found] ` <5fd50e9.def5d621.180f273d002@tnonline.net>
2022-05-23 20:00   ` efkf
2022-05-23 20:05     ` efkf
2022-05-24  6:51       ` efkf
2022-05-24 19:11         ` Chris Murphy
2022-05-27 15:13           ` efkf
2022-05-27 15:15             ` efkf
2022-05-27 15:25             ` Forza
2022-05-27 16:28               ` efkf
2022-05-27 21:37                 ` Forza
2022-05-28 20:20           ` Nicholas D Steeves [this message]
2022-05-28 21:04             ` Forza
2022-05-29 20:48             ` efkf
2022-05-30 20:47               ` Forza
2022-05-30 21:59                 ` Graham Cobb
2022-06-07 21:17                   ` Nicholas D Steeves

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=87tu99h0ic.fsf@DigitalMercury.freeddns.org \
    --to=nsteeves@gmail.com \
    --cc=1i5t5.duncan@cox.net \
    --cc=efkf@firemail.cc \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=lists@colorremedies.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.