From: Gionatan Danti <g.danti@assyoma.it>
To: LVM general discussion and development <linux-lvm@redhat.com>
Cc: Stuart, Zhong Lidong <lidong.zhong@suse.com>,
David Teigland <teigland@redhat.com>,
Zdenek Kabelac <zkabelac@redhat.com>
Subject: Re: [linux-lvm] Does LVM have any plan/schedule to support btrfs in fsadm
Date: Mon, 28 Jun 2021 09:29:19 +0200 [thread overview]
Message-ID: <35d4978f0aa1c0a78c8c618557ba15e5@assyoma.it> (raw)
In-Reply-To: <b0c22aef-8a9-73e6-db74-c24633c3496@gathman.org>
Il 2021-06-28 05:28 Stuart D Gathman ha scritto:
> Yes. I like the checksums in metadata feature for enhanced integrity
> checking.
Until recently btrfs has issue when a LVM snapshot was mounted. It is
now solved?
> It seems too complicated to have anytime soon - but when a filesystem
> detects corruption, and is on an LVM (or md) RAID1 layer, an ioctl to
> read alternate mirror branches to see which (if any) has the correct
> data would allow recovery. Btrfs does this if it is doing the
> mirroring, but then you lose all the other features from LVM or md
> raid10, including running other filesystems and efficient virtual
> disks for
> virtual machines.
For this to work, LVM should be able to identify the corrupted data.
Without checksum, how can you do that? The solution is to use
dm-integrity under the RAID layer. It works pretty well, letting apart
the big performance drop in the default (journaled) configuration
(bitmap is faster, but leave a small window for corruption to happen
undetected).
That said, for rewrite-heavy workload (virtual machines, databases, etc)
btrfs is very slow (and disabling CoW is not a solution for me, as it
also disables checksum, compression, etc).
> We eventually got DISCARD operations to pass to lower layers.
> Dealing with mirror branches should really be a thing too.
As said above, the issue is not to read from the mirror leg separately;
rather, to detect *which* mirror leg contains valid data.
Regards.
--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti@assyoma.it - info@assyoma.it
GPG public key ID: FF5F32A8
_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
next prev parent reply other threads:[~2021-06-28 7:32 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-25 5:28 [linux-lvm] Does LVM have any plan/schedule to support btrfs in fsadm heming.zhao
2021-06-25 10:57 ` Zdenek Kabelac
2021-06-27 17:40 ` heming.zhao
2021-06-28 3:28 ` Stuart D Gathman
2021-06-28 7:29 ` Gionatan Danti [this message]
2021-06-28 23:00 ` Chris Murphy
2021-06-29 22:32 ` Gionatan Danti
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=35d4978f0aa1c0a78c8c618557ba15e5@assyoma.it \
--to=g.danti@assyoma.it \
--cc=lidong.zhong@suse.com \
--cc=linux-lvm@redhat.com \
--cc=teigland@redhat.com \
--cc=zkabelac@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.