On Sat, Feb 15, 2020 at 12:22 PM Gionatan Danti <g.danti@xxxxxxxxxx> wrote: > > Il 2020-02-15 13:40 Zdenek Kabelac ha scritto: > > It's worth to note lvm2 is solving way more issues then other similar > > device technology (i.e. mdraid, btrfs....) where it's very simple to > > cause big confusion and data corruptions (even unnoticed) once > > duplicates appears in your system... > > > > Zdenek > > I never duplicate devices with mdraid, but BTRFS is so fragile that > taking a simple LVM snapshot of a BTRFS component device can lead to > data corruption. > > I really think the gold standard here is ZFS. Are you referring to this known problem? https://btrfs.wiki.kernel.org/index.php/Gotchas#Block-level_copies_of_devices 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). 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. 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. -- Chris Murphy _______________________________________________ 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/
