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@xxxxxxxxxx> 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 */ -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
