Re: btrfs dev del not transaction protected?

Qu Wenruo
2019-12-20T05:24:29Z

[-- 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 --]