archive mirror
 help / color / mirror / Atom feed
From: Sebastian Bachmann <>
Subject: Re: [linux-lvm] move dm-integrity metadata to another PV
Date: Mon, 5 Apr 2021 17:40:20 +0200	[thread overview]
Message-ID: <20210405154020.yuscn36x37g64ly7@helios> (raw)
In-Reply-To: <>

On Mon, Apr 05, 2021 at 10:08:22AM -0500, David Teigland wrote:
> On Sun, Apr 04, 2021 at 08:18:56PM +0200, Sebastian Bachmann wrote:
> > Hello,
> > 
> > I played around with the new dm-integrity integration in lvm. Unfortunately, it
> > is very slow, as the checksums has to be written and read on - which is the
> > price to pay obviously.
> > 
> > I thought that it might be a good idea to move the metadata to a fast disk,
> > i.e., a SSD, however that is not possible and I get an error message on pvmove:
> > 
> > # pvmove -n r10_int_rimage_0_imeta /dev/sdd /dev/sda2
> >   Unable to pvmove device used for raid with integrity.
> > 
> > I could not find a reason why this should not be done in theory, thus I guess
> > that this is simply not supported by LVM right now?
> > Or is there another reason why you should keep the metadata always on the same
> > device?
> The original implementation allowed a specific device, e.g. an ssd, to
> hold all the integrity metadata.  Integrity metadata for all raid images
> lived on one device, so there was some doubt that anyone would want to use
> it, and the option was dropped.  That option could also be used with
> linear+integrity.  Without raid, corrupt data found by integrity couldn't
> be recovered, so linear+integrity was also disabled.  Given those
> limitations, I'm curious how useful you'd find a dedicated integrity
> metadata device, and/or using integrity with a linear LV?

Ah okay, I did not knew that it was already considered.

So the worst case would be, that the SSD and an HDD gets corrupted at the same
time and you would not be able to recover the integrity data and would not
detect the corruption on the disk. For a RAID, you would still see that there is
a corruption but for linear you would not know that there was a corruption,

Right now, I have a RAID without any integrity, thus enabling it on
another disk is in any case an improvement. I think loosing the SSD with the
integrity data is in that case not as bad as having slow reading/writing.

For the linear case, I would say it would be still useful. For example, you
would be able to know that something is wrong and could start to investigate.
I guess it would be a bad idea to put too much faith in that setup though.
How is this implemented for example on btrfs?

Maybe having a RAID of the metadata would be an option...

But I have not thought that through fully, so maybe there is something that I


linux-lvm mailing list
read the LVM HOW-TO at

      reply	other threads:[~2021-04-05 15:41 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-04 18:18 [linux-lvm] move dm-integrity metadata to another PV Sebastian Bachmann
2021-04-05  0:59 ` Erwin van Londen
2021-04-05 15:08 ` David Teigland
2021-04-05 15:40   ` Sebastian Bachmann [this message]

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210405154020.yuscn36x37g64ly7@helios \ \ \ \

* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).