[dm-devel] Integrity discard/trim extremely slow on NVMe SSD storage (~10GiB/minute)

[Mikulas Patocka]

On Mon, 26 Apr 2021, Mikulas Patocka wrote:

> > Further tests on the same machine show that SATA SSD is not affected by this 
> > issue and discards at high performance. Appears to be NVMe-specific bug:
> > Ref: https://gitlab.com/cryptsetup/cryptsetup/-/issues/639#note_555208783
> 
> I tried it on my nvme device (Samsung SSD 960 EVO 500GB) and I could 
> discard 32GB in 5 seconds.
> 
> I assume that it is specific to the nvme device you are using. The device 
> is perhaps slow due to a mix of dicard+read+write requests that 
> dm-integrity generates.
> 
> > If there is anything I can do to help feel free to let me know.
> > Note that I am not subscribed to dm-level, please CC me directly.
> > 
> > Thanks,
> 
> Could you try it on other nvme disks?

Try this patch - it will avoid writing discard filler to metadata if it is 
already there. It won't help on the first discard, but it may help when 
discarding already discarded blocks.

Mikulas



dm-integrity: don't write metadata if we overwrite it with the same content

If we discard already discarded blocks, we do not need to write discard
filler to the metadata, because it is already there.

Signed-off-by: Mikulas Patocka <mpatocka at 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
@@ -1429,8 +1429,10 @@ static int dm_integrity_rw_tag(struct dm
 		if (op == TAG_READ) {
 			memcpy(tag, dp, to_copy);
 		} else if (op == TAG_WRITE) {
-			memcpy(dp, tag, to_copy);
-			dm_bufio_mark_partial_buffer_dirty(b, *metadata_offset, *metadata_offset + to_copy);
+			if (memcmp(dp, tag, to_copy)) {
+				memcpy(dp, tag, to_copy);
+				dm_bufio_mark_partial_buffer_dirty(b, *metadata_offset, *metadata_offset + to_copy);
+			}
 		} else {
 			/* e.g.: op == TAG_CMP */