[linux-lvm] commit c527a0cbfc3 may have a bug

[Chris Murphy]

On Sat, Feb 15, 2020 at 12:22 PM Gionatan Danti <g.danti at assyoma.it> 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