From: Melvin Vermeeren <vermeeren@vermwa.re>
To: Mike Snitzer <msnitzer@redhat.com>, Milan Broz <mbroz@redhat.com>,
Mikulas Patocka <mpatocka@redhat.com>
Cc: dm-devel@redhat.com
Subject: Re: [dm-devel] [PATCH v2] dm-integrity: if we have discard support, use it when recalculating
Date: Fri, 30 Apr 2021 21:39:46 +0200 [thread overview]
Message-ID: <6810395.sd9NxXGo4T@verm-r4e> (raw)
In-Reply-To: <alpine.LRH.2.02.2104281658430.9959@file01.intranet.prod.int.rdu2.redhat.com>
[-- Attachment #1.1: Type: text/plain, Size: 1909 bytes --]
Hi again,
On Wednesday, 28 April 2021 23:00:23 CEST Mikulas Patocka wrote:
> Here I'm sending version 2 of the patch - it increases version number of
> the target, so that userspace can test if this feature is present.
>
> From: Mikulas Patocka <mpatocka@redhat.com>
>
> If we have discard support, we don't have to recalculate hash - we can
> just fill the metadata with the discard pattern.
>
> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
I had a look at this patch. If I understand correctly, this logic only applies
to dm-integrity recalculation, so for example from userspace with:
$ integritysetup --integrity-recalculate --allow-discards open <dev> <name>
In such a case, it will fill all tag values with discard filler instead of
reading from the drive and computing the tags. If that is true I think this is
not desired behaviour, consider the following:
* SSD with existing data /dev/sda1.
* Device for dm-integrity metadata /dev/vg/is_sda1_meta.
* $ integritysetup --data-device /dev/sda1 --no-wipe /dev/vg/is_sda1_meta
* $ integritysetup --data-device /dev/sda1 --integrity-recalculate \
--allow-discards open /dev/vg/is_sda1_meta is_sda1
In current production version, this causes a full read of the SSD to
recalculate integrity tags, which is as expected and works very nicely. With
this patch, wouldn't it result in all integrity tags being set to the discard
filler? Does this patch assume a device is fully discarded when recalculating?
Perhaps I am reading it wrong, I am not familiar with the dm kernel modules.
Also, a bit unrelated to any of the above. When doing a format operation
(without --no-wipe) on a device supporting discard, would it not be possible
to format via discards instead of the current data write operations? That
would significantly improve speed for SSDs and also reduce wear on the drive.
Thanks,
--
Melvin Vermeeren
Systems engineer
[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 97 bytes --]
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
next prev parent reply other threads:[~2021-05-03 11:13 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-28 21:00 [dm-devel] [PATCH v2] dm-integrity: if we have discard support, use it when recalculating Mikulas Patocka
2021-04-30 19:39 ` Melvin Vermeeren [this message]
2021-05-05 18:48 ` Mikulas Patocka
2021-05-05 19:27 ` Melvin Vermeeren
2021-05-05 20:05 ` Mikulas Patocka
2021-05-05 20:16 ` Melvin Vermeeren
2021-05-05 20:45 ` Mikulas Patocka
2021-05-05 21:47 ` Melvin Vermeeren
2021-05-11 17:06 ` Milan Broz
2021-05-11 18:33 ` Melvin Vermeeren
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=6810395.sd9NxXGo4T@verm-r4e \
--to=vermeeren@vermwa.re \
--cc=dm-devel@redhat.com \
--cc=mbroz@redhat.com \
--cc=mpatocka@redhat.com \
--cc=msnitzer@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.