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@xxxxxxxxxx - info@xxxxxxxxxx GPG public key ID: FF5F32A8 _______________________________________________ linux-lvm mailing list linux-lvm@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
