[linux-lvm] commit c527a0cbfc3 may have a bug

[Gionatan Danti]

Il 2020-02-15 21:49 Chris Murphy ha scritto:
> Are you referring to this known problem?
> https://btrfs.wiki.kernel.org/index.php/Gotchas#Block-level_copies_of_devices

Yes.

> By default the snapshot LV isn't active, so the problem doesn't
> happen. I've taken many LVM thinp snapshots of Btrfs file systems,
> including while they're actively being written to, and never run into
> this problem (or any other).

Thin LVM snapshots are not active by default, yes. But you *need* to 
activate them to access their data.
Moreover, classical (non-thin) LVM snapshot are automatically activated 
when taken.

> An LVM snapshot comes with FIFREEZE, and supported filesystems,
> including Btrfs, should have a consistent snapshot created as a
> result. I don't think ZFS supports FIFREEZE/FITHAW and if that's
> correct, you're effectively getting a powerfail/crash type behavior
> with an LVM snapshot of a ZFS file system, entirely trusting on its
> own ability to maintain file system consistency.

True, but the transactional nature of ZFS writes means that a clean 
recovery option should always be available. Anyway, any modern journaled 
filesystem will not corrupt itself on power loss/recovery (async write 
back data will be lost, obviously).

> My dualist opinion on mixing these layers: while it should work, and
> if there's corruption then there's a bug somewhere, adding layers
> increases complexity and thus risk. That's possibly a good idea in a
> testing/qualification context, where you want something sensitive to
> and consistently flags any discrepancy. That's not fragility.

I am not sure about that: one of BTRFS main goal was to not duplicate 
code, relying on standard Linux block device behavior as much as 
possible. For this reason, I tend to think that snapshotting (and using) 
the block device under a BTRFS device should be a supported use case.

But hey - the LVM team is really doing an awesome work!
Thanks.

-- 
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it [1]
email: g.danti at assyoma.it - info at assyoma.it
GPG public key ID: FF5F32A8