All of lore.kernel.org
 help / color / mirror / Atom feed
* [dm-devel] [PATCH v2] dm-integrity: if we have discard support, use it when recalculating
@ 2021-04-28 21:00 Mikulas Patocka
  2021-04-30 19:39 ` Melvin Vermeeren
  0 siblings, 1 reply; 10+ messages in thread
From: Mikulas Patocka @ 2021-04-28 21:00 UTC (permalink / raw)
  To: Mike Snitzer, Milan Broz; +Cc: dm-devel, Melvin Vermeeren

Hi

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.

Mikulas



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>

Index: linux-2.6/drivers/md/dm-integrity.c
===================================================================
--- linux-2.6.orig/drivers/md/dm-integrity.c
+++ linux-2.6/drivers/md/dm-integrity.c
@@ -2690,26 +2690,30 @@ next_chunk:
 	if (unlikely(dm_integrity_failed(ic)))
 		goto err;
 
-	io_req.bi_op = REQ_OP_READ;
-	io_req.bi_op_flags = 0;
-	io_req.mem.type = DM_IO_VMA;
-	io_req.mem.ptr.addr = ic->recalc_buffer;
-	io_req.notify.fn = NULL;
-	io_req.client = ic->io;
-	io_loc.bdev = ic->dev->bdev;
-	io_loc.sector = get_data_sector(ic, area, offset);
-	io_loc.count = n_sectors;
+	if (!ic->discard) {
+		io_req.bi_op = REQ_OP_READ;
+		io_req.bi_op_flags = 0;
+		io_req.mem.type = DM_IO_VMA;
+		io_req.mem.ptr.addr = ic->recalc_buffer;
+		io_req.notify.fn = NULL;
+		io_req.client = ic->io;
+		io_loc.bdev = ic->dev->bdev;
+		io_loc.sector = get_data_sector(ic, area, offset);
+		io_loc.count = n_sectors;
 
-	r = dm_io(&io_req, 1, &io_loc, NULL);
-	if (unlikely(r)) {
-		dm_integrity_io_error(ic, "reading data", r);
-		goto err;
-	}
+		r = dm_io(&io_req, 1, &io_loc, NULL);
+		if (unlikely(r)) {
+			dm_integrity_io_error(ic, "reading data", r);
+			goto err;
+		}
 
-	t = ic->recalc_tags;
-	for (i = 0; i < n_sectors; i += ic->sectors_per_block) {
-		integrity_sector_checksum(ic, logical_sector + i, ic->recalc_buffer + (i << SECTOR_SHIFT), t);
-		t += ic->tag_size;
+		t = ic->recalc_tags;
+		for (i = 0; i < n_sectors; i += ic->sectors_per_block) {
+			integrity_sector_checksum(ic, logical_sector + i, ic->recalc_buffer + (i << SECTOR_SHIFT), t);
+			t += ic->tag_size;
+		}
+	} else {
+		t = ic->recalc_tags + (n_sectors >> ic->sb->log2_sectors_per_block) * ic->tag_size;
 	}
 
 	metadata_block = get_metadata_sector_and_offset(ic, area, offset, &metadata_offset);
@@ -4364,11 +4368,13 @@ try_smaller_buffer:
 			goto bad;
 		}
 		INIT_WORK(&ic->recalc_work, integrity_recalc);
-		ic->recalc_buffer = vmalloc(RECALC_SECTORS << SECTOR_SHIFT);
-		if (!ic->recalc_buffer) {
-			ti->error = "Cannot allocate buffer for recalculating";
-			r = -ENOMEM;
-			goto bad;
+		if (!ic->discard) {
+			ic->recalc_buffer = vmalloc(RECALC_SECTORS << SECTOR_SHIFT);
+			if (!ic->recalc_buffer) {
+				ti->error = "Cannot allocate buffer for recalculating";
+				r = -ENOMEM;
+				goto bad;
+			}
 		}
 		ic->recalc_tags = kvmalloc_array(RECALC_SECTORS >> ic->sb->log2_sectors_per_block,
 						 ic->tag_size, GFP_KERNEL);
@@ -4377,6 +4383,8 @@ try_smaller_buffer:
 			r = -ENOMEM;
 			goto bad;
 		}
+		if (ic->discard)
+			memset(ic->recalc_tags, DISCARD_FILLER, (RECALC_SECTORS >> ic->sb->log2_sectors_per_block) * ic->tag_size);
 	} else {
 		if (ic->sb->flags & cpu_to_le32(SB_FLAG_RECALCULATING)) {
 			ti->error = "Recalculate can only be specified with internal_hash";
@@ -4570,7 +4578,7 @@ static void dm_integrity_dtr(struct dm_t
 
 static struct target_type integrity_target = {
 	.name			= "integrity",
-	.version		= {1, 8, 0},
+	.version		= {1, 9, 0},
 	.module			= THIS_MODULE,
 	.features		= DM_TARGET_SINGLETON | DM_TARGET_INTEGRITY,
 	.ctr			= dm_integrity_ctr,

--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dm-devel] [PATCH v2] dm-integrity: if we have discard support, use it when recalculating
  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
  2021-05-05 18:48   ` Mikulas Patocka
  0 siblings, 1 reply; 10+ messages in thread
From: Melvin Vermeeren @ 2021-04-30 19:39 UTC (permalink / raw)
  To: Mike Snitzer, Milan Broz, Mikulas Patocka; +Cc: dm-devel


[-- 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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dm-devel] [PATCH v2] dm-integrity: if we have discard support, use it when recalculating
  2021-04-30 19:39 ` Melvin Vermeeren
@ 2021-05-05 18:48   ` Mikulas Patocka
  2021-05-05 19:27     ` Melvin Vermeeren
  0 siblings, 1 reply; 10+ messages in thread
From: Mikulas Patocka @ 2021-05-05 18:48 UTC (permalink / raw)
  To: Melvin Vermeeren; +Cc: Mike Snitzer, dm-devel, Milan Broz



On Fri, 30 Apr 2021, Melvin Vermeeren wrote:

> 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?

It doesn't matter if the device is discarded or not. If the metadata 
constains the discard filler, dm-integrity won't check the checksum - so 
the data can contain anything.

> 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.

You don't have to discard the device when initializing it.

The device after discard may contain random pattern (some SSDs really do) 
- so when the metadata contains the discard filler, the data may contain 
anything.

> Thanks,

Mikulas

--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dm-devel] [PATCH v2] dm-integrity: if we have discard support, use it when recalculating
  2021-05-05 18:48   ` Mikulas Patocka
@ 2021-05-05 19:27     ` Melvin Vermeeren
  2021-05-05 20:05       ` Mikulas Patocka
  0 siblings, 1 reply; 10+ messages in thread
From: Melvin Vermeeren @ 2021-05-05 19:27 UTC (permalink / raw)
  To: Mikulas Patocka; +Cc: Mike Snitzer, dm-devel, Milan Broz


[-- Attachment #1.1: Type: text/plain, Size: 954 bytes --]

Hi,

On Wednesday, 5 May 2021 20:48:47 CEST Mikulas Patocka wrote:
> It doesn't matter if the device is discarded or not. If the metadata
> constains the discard filler, dm-integrity won't check the checksum - so
> the data can contain anything.
> 
> ...
>
> The device after discard may contain random pattern (some SSDs really do)
> - so when the metadata contains the discard filler, the data may contain
> anything.

So if an existing SSD is formatted with --no-wipe --data-device option and 
then opened with --integrity-recalculate all metadata will contain the discard 
filler with this patch.

So then, all the current data in the drive is not checked for integrity 
because it contains discard filler. This means that integrity recalculation 
itself never takes place for existing data. Meaning that only newly written 
data to SSD device will actually have integrity protection.

Is this correct?

Cheers,

-- 
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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dm-devel] [PATCH v2] dm-integrity: if we have discard support, use it when recalculating
  2021-05-05 19:27     ` Melvin Vermeeren
@ 2021-05-05 20:05       ` Mikulas Patocka
  2021-05-05 20:16         ` Melvin Vermeeren
  0 siblings, 1 reply; 10+ messages in thread
From: Mikulas Patocka @ 2021-05-05 20:05 UTC (permalink / raw)
  To: Melvin Vermeeren; +Cc: Mike Snitzer, dm-devel, Milan Broz



On Wed, 5 May 2021, Melvin Vermeeren wrote:

> Hi,
> 
> On Wednesday, 5 May 2021 20:48:47 CEST Mikulas Patocka wrote:
> > It doesn't matter if the device is discarded or not. If the metadata
> > constains the discard filler, dm-integrity won't check the checksum - so
> > the data can contain anything.
> > 
> > ...
> >
> > The device after discard may contain random pattern (some SSDs really do)
> > - so when the metadata contains the discard filler, the data may contain
> > anything.
> 
> So if an existing SSD is formatted with --no-wipe --data-device option and 
> then opened with --integrity-recalculate all metadata will contain the discard 
> filler with this patch.
> 
> So then, all the current data in the drive is not checked for integrity 
> because it contains discard filler. This means that integrity recalculation 
> itself never takes place for existing data. Meaning that only newly written 
> data to SSD device will actually have integrity protection.
> 
> Is this correct?

Yes.

Mikulas

> Cheers,
> 
> -- 
> Melvin Vermeeren
> Systems engineer

--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dm-devel] [PATCH v2] dm-integrity: if we have discard support, use it when recalculating
  2021-05-05 20:05       ` Mikulas Patocka
@ 2021-05-05 20:16         ` Melvin Vermeeren
  2021-05-05 20:45           ` Mikulas Patocka
  0 siblings, 1 reply; 10+ messages in thread
From: Melvin Vermeeren @ 2021-05-05 20:16 UTC (permalink / raw)
  To: Mikulas Patocka; +Cc: Mike Snitzer, dm-devel, Milan Broz


[-- Attachment #1.1: Type: text/plain, Size: 746 bytes --]

On Wednesday, 5 May 2021 22:05:35 CEST Mikulas Patocka wrote:
> Yes.

I fail to understand why that would be desired behaviour, as I see it it is 
conflicting with current documentation in integritysetup(8):

> --integrity-recalculate
> Automatically recalculate integrity tags in kernel on activation. The device
> can be used during automatic integrity recalculation but becomes fully
> integrity protected only after the background operation is finished. This
> option is available since the Linux kernel version 4.19.

The device in SSD with discard case never receives integrity protection 
because the metadata is filled with discard filler. Could you explain the 
reasoning behind the patch?

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dm-devel] [PATCH v2] dm-integrity: if we have discard support, use it when recalculating
  2021-05-05 20:16         ` Melvin Vermeeren
@ 2021-05-05 20:45           ` Mikulas Patocka
  2021-05-05 21:47             ` Melvin Vermeeren
  0 siblings, 1 reply; 10+ messages in thread
From: Mikulas Patocka @ 2021-05-05 20:45 UTC (permalink / raw)
  To: Melvin Vermeeren; +Cc: Mike Snitzer, dm-devel, Milan Broz



On Wed, 5 May 2021, Melvin Vermeeren wrote:

> On Wednesday, 5 May 2021 22:05:35 CEST Mikulas Patocka wrote:
> > Yes.
> 
> I fail to understand why that would be desired behaviour, as I see it it is 
> conflicting with current documentation in integritysetup(8):

So, we can ask Milan to update the manpage.

> > --integrity-recalculate
> > Automatically recalculate integrity tags in kernel on activation. The device
> > can be used during automatic integrity recalculation but becomes fully
> > integrity protected only after the background operation is finished. This
> > option is available since the Linux kernel version 4.19.
> 
> The device in SSD with discard case never receives integrity protection 
> because the metadata is filled with discard filler. Could you explain the 
> reasoning behind the patch?

It will receive integrity protection for the newly written data.

If you create an integrity device and make a filesystem on it, the newly 
written data matters. The old data that were on the filesystem before 
formatting it don't care and don't need to be protected.

> Thanks,

Mikulas

--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dm-devel] [PATCH v2] dm-integrity: if we have discard support, use it when recalculating
  2021-05-05 20:45           ` Mikulas Patocka
@ 2021-05-05 21:47             ` Melvin Vermeeren
  2021-05-11 17:06               ` Milan Broz
  0 siblings, 1 reply; 10+ messages in thread
From: Melvin Vermeeren @ 2021-05-05 21:47 UTC (permalink / raw)
  To: Mikulas Patocka; +Cc: Mike Snitzer, dm-devel, Milan Broz


[-- Attachment #1.1: Type: text/plain, Size: 1932 bytes --]

Hi,

On Wednesday, 5 May 2021 22:45:09 CEST Mikulas Patocka wrote:
> So, we can ask Milan to update the manpage.

Yes, that would be fine. However, "integrity recalculate" sounds like 
recalculating integrity. The newly implemented logic is more of a "integrity 
wipe" or "integrity reset".

What is problematic is that actual functionality from end user point of view 
is now completely different depending on if you use --allow-discards or not. 
Without discard you recalculate meta, with discard you reset/wipe meta.

> It will receive integrity protection for the newly written data.
> 
> If you create an integrity device and make a filesystem on it, the newly
> written data matters. The old data that were on the filesystem before
> formatting it don't care and don't need to be protected.

One of the current possible use cases with --no-wipe --data-device is that you 
can use existing device holding data that has no integrity and add integrity 
to it with detached metadata device in combination with recalculate.

Then recalculation can be used in a fashion similar to trust-on-first-use for 
this specific disk without rewriting the data meaning also no temporary copy 
is needed. This feature is something I have used a few times as adding 
integrity in-place can be useful in certain situations especially when dealing 
with large amounts of data.


I am not against the new reset/wipe operation, it is certainly a useful thing 
to have. This style of initialising metadata would be especially useful with 
formatting devices supporting discard, as it could be used to avoid 
unnecessary writes on main data by initialising metadata only (and perhaps 
also issue discards to underlying device).

But I do think this should be a separate, new function in addition to existing 
recalculation feature, to me they both seem useful in different use cases.

Thoughts on this?

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dm-devel] [PATCH v2] dm-integrity: if we have discard support, use it when recalculating
  2021-05-05 21:47             ` Melvin Vermeeren
@ 2021-05-11 17:06               ` Milan Broz
  2021-05-11 18:33                 ` Melvin Vermeeren
  0 siblings, 1 reply; 10+ messages in thread
From: Milan Broz @ 2021-05-11 17:06 UTC (permalink / raw)
  To: Melvin Vermeeren, Mikulas Patocka; +Cc: Mike Snitzer, dm-devel

On 05/05/2021 23:47, Melvin Vermeeren wrote:
> Hi,
> 
> On Wednesday, 5 May 2021 22:45:09 CEST Mikulas Patocka wrote:
>> So, we can ask Milan to update the manpage.
> 
> Yes, that would be fine. However, "integrity recalculate" sounds like 
> recalculating integrity. The newly implemented logic is more of a "integrity 
> wipe" or "integrity reset".
> 
> What is problematic is that actual functionality from end user point of view 
> is now completely different depending on if you use --allow-discards or not. 
> Without discard you recalculate meta, with discard you reset/wipe meta.
> 
>> It will receive integrity protection for the newly written data.
>>
>> If you create an integrity device and make a filesystem on it, the newly
>> written data matters. The old data that were on the filesystem before
>> formatting it don't care and don't need to be protected.

This is not true. Imagine blkid that tries to read various superblocks on disk
and do decisions based on it (UUID links etc). These can be in "unused" sectors.

In the normal situation dm-integrity stops the read, because checksum is wrong.
Now it seems that it returns these random data. This is not integrity protection at all.

Maybe I am missing something, but I would say this is a wrong behavior and it should
be reverted. I think this should be not supported even with additional switch,
to me is it really against the principle of sector-level integrity protection.

Also, I added wiping to integritysetup because some tools (like mkfs) actually
needef to read unitialized data before creating metadata - so without previous wipe it failed.
(These are bugs in the tools, obviously: I plan to report these  unfortunately it never happened.
Dunno if it is still the case.)

Sorry for the late reply.

Milan


> 
> One of the current possible use cases with --no-wipe --data-device is that you 
> can use existing device holding data that has no integrity and add integrity 
> to it with detached metadata device in combination with recalculate.
> 
> Then recalculation can be used in a fashion similar to trust-on-first-use for 
> this specific disk without rewriting the data meaning also no temporary copy 
> is needed. This feature is something I have used a few times as adding 
> integrity in-place can be useful in certain situations especially when dealing 
> with large amounts of data.
> 
> 
> I am not against the new reset/wipe operation, it is certainly a useful thing 
> to have. This style of initialising metadata would be especially useful with 
> formatting devices supporting discard, as it could be used to avoid 
> unnecessary writes on main data by initialising metadata only (and perhaps 
> also issue discards to underlying device).
> 
> But I do think this should be a separate, new function in addition to existing 
> recalculation feature, to me they both seem useful in different use cases.
> 
> Thoughts on this?
> 
> Thanks,
> 

--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dm-devel] [PATCH v2] dm-integrity: if we have discard support, use it when recalculating
  2021-05-11 17:06               ` Milan Broz
@ 2021-05-11 18:33                 ` Melvin Vermeeren
  0 siblings, 0 replies; 10+ messages in thread
From: Melvin Vermeeren @ 2021-05-11 18:33 UTC (permalink / raw)
  To: Milan Broz; +Cc: Mike Snitzer, Mikulas Patocka, dm-devel


[-- Attachment #1.1: Type: text/plain, Size: 1188 bytes --]

Hi Milan,

On Tuesday, 11 May 2021 19:06:53 CEST Milan Broz wrote:
> Also, I added wiping to integritysetup because some tools (like mkfs)
> actually needef to read unitialized data before creating metadata - so
> without previous wipe it failed. (These are bugs in the tools, obviously: I
> plan to report these  unfortunately it never happened. Dunno if it is still
> the case.)

I can confirm a lot of tools still do this. Even `blkdiscard` probes for 
filesystems as a sanity check before discarding. So in order to efficiently 
initialise SSD without wiping, you need to dd zero to the start and end before 
running blkdiscard, or use --no-wipe with (pre-patch) recalculate.

Also, I did not realise the wiping is fully done from integritysetup 
userspace, this means the statement that this option would be useful as a new 
one is flawed, so then I agree the patch should be reverted.

It would be nice however if integritysetup from userspace has a native feature 
to wipe devices supporting discard with discards instead of writing (zeroes?), 
perhaps in the form of a --wipe-discard flag or similar, but that's for 
another day. :)

Cheers,

-- 
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

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2021-05-12  5:58 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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

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.