From: Marc Lehmann <schmorp@schmorp.de>
To: linux-btrfs@vger.kernel.org
Subject: btrfs dev del not transaction protected?
Date: Fri, 20 Dec 2019 05:05:37 +0100 [thread overview]
Message-ID: <20191220040536.GA1682@schmorp.de> (raw)
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.
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
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 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
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
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schmorp@schmorp.de
-=====/_/_//_/\_,_/ /_/\_\
next reply other threads:[~2019-12-20 4:44 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-20 4:05 Marc Lehmann [this message]
2019-12-20 5:24 ` btrfs dev del not transaction protected? Qu Wenruo
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=20191220040536.GA1682@schmorp.de \
--to=schmorp@schmorp.de \
--cc=linux-btrfs@vger.kernel.org \
/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.