All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Marc Lehmann <schmorp@schmorp.de>, linux-btrfs@vger.kernel.org
Subject: Re: btrfs dev del not transaction protected?
Date: Fri, 20 Dec 2019 13:24:20 +0800	[thread overview]
Message-ID: <b9e7f094-0080-ef08-68df-61ffbeaa9d19@gmx.com> (raw)
In-Reply-To: <20191220040536.GA1682@schmorp.de>


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



On 2019/12/20 下午12:05, Marc Lehmann wrote:
> Hi!
> 
> I used btrfs del /somedevice /mountpoint to remove a device, and then typed
> sync. A short time later the system had a hard reset.

Then it doesn't look like the title.

Normally for sync, btrfs will commit transaction, thus even something
like the title happened, you shouldn't be affected at all.

> 
> Now the file system doesn't mount read-write anymore because it complains
> about a missing device (linux 5.4.5):
> 
> [  247.385346] BTRFS error (device dm-32): devid 1 uuid f5c3dc63-1fac-45b3-b9ba-ed1ec5f92403 is missing
> [  247.386942] BTRFS error (device dm-32): failed to read chunk tree: -2
> [  247.462693] BTRFS error (device dm-32): open_ctree failed

Is that devid 1 the device you tried to deleted?
Or some unrelated device?

> 
> The thing is, the device is still there and accessible, but btrfs no longer
> recognises it, as it already deleted it before the crash.

I think it's not what you thought, but btrfs device scan is not properly
triggered.

Would you please give some more dmesg? As each scanned btrfs device will
show up in dmesg.
That would help us to pin down the real cause.

> 
> I can mount the filesystem in degraded mode, and I have a backup in case
> somehting isn't readable, so this is merely a costly inconvinience for me
> (it's a 40TB volume), but this seems very unexpected, both that device
> dels apparently have a race condition and that sync doesn't actually
> synchronise the filesystem - I naively expected that btrfs dev del doesn't
> cause the loss of the filesystem due to a system crash.
> 
> Probably nbot related, but maybe worth mentioning: I found that system
> crashes (resets, not power failures) cause btrfs to not mount the first
> time a mount is attempted, but it always succeeds the second time, e.g.:
> 
>    # mount /device /mnt
>    ... no errors or warnings in kernel log, except:
>    BTRFS error (device dm-34): open_ctree failed
>    # mount /device /mnt
>    magically succeeds

Yep, this makes it sound more like a scan related bug.

Thanks,
Qu

> 
> The typical symptom here is that systemd goes into emergency mode on mount
> failure, but simpyl rebooting, or executing the mount manually then succeeds.
> 
> Greetings,
> Marc
> 


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

  reply	other threads:[~2019-12-20  5:24 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-20  4:05 btrfs dev del not transaction protected? Marc Lehmann
2019-12-20  5:24 ` Qu Wenruo [this message]
2019-12-20  6:37   ` Marc Lehmann
2019-12-20  7:10     ` Qu Wenruo
2019-12-20 13:27       ` Marc Lehmann
2019-12-20 13:41         ` Qu Wenruo
2019-12-20 16:53           ` Marc Lehmann
2019-12-20 17:24             ` Remi Gauvin
2019-12-20 17:50               ` Marc Lehmann
2019-12-20 18:00               ` Marc Lehmann
2019-12-20 18:28                 ` Eli V
2019-12-20 20:24             ` Chris Murphy
2019-12-20 23:30               ` Marc Lehmann
2019-12-21 20:06               ` Zygo Blaxell
2019-12-21  1:32             ` Qu Wenruo
2019-12-20 17:07           ` Marc Lehmann
2019-12-21  1:23             ` Qu Wenruo
2019-12-20 17:20           ` Marc Lehmann

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=b9e7f094-0080-ef08-68df-61ffbeaa9d19@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=schmorp@schmorp.de \
    /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.