dm-delay has a flush delay class: the 9-argument table form takes <flush_device> <flush_offset> <flush_delay>, delay_map() routes REQ_PREFLUSH bios to it, num_flush_bios is 1, and Documentation/admin-guide/device-mapper/delay.rst documents it. But the target never sets ti->flush_supported, so the dm device only supports flushes when an underlying device stacks BLK_FEAT_WRITE_CACHE into its limits. Over a write-through device (write_cache "write through") it does not: submit_bio_noacct() strips REQ_PREFLUSH and REQ_FUA before any bio reaches the target, and a configured flush delay measures nothing.
Set ti->flush_supported when dc->flush.delay is non-zero. A configured flush delay then always sees its flushes. Without one, dm-delay keeps stacking flush support from the underlying device like the other targets, so an undelayed dm-delay behaves like linear for flushes. As for any table with flush support, the dm queue then also advertises FUA; delay_map() keeps routing REQ_FUA writes to the write class, and only REQ_PREFLUSH goes to the flush class. Verified in a VM with dm-delay over a write-through virtio-scsi disk, using a 9-argument table with write delay 0 and a flush delay of 200 or 800 ms. Without this change the dm queue reports write_cache "write through", fua 0, and five 4 KiB dd oflag=dsync writes to the dm device complete in 0-1 ms. With it the queue reports "write back", fua 1, and the same writes take 204-210 ms and 812-880 ms. Zero-delay tables over the write-through disk and over a write-back disk behave the same with and without the change and keep the underlying queue's settings. Suggested-by: Benjamin Marzinski <[email protected]> Signed-off-by: Matthias Goergens <[email protected]> --- Changes since v1: - Set flush_supported only when dc->flush.delay is non-zero, so an undelayed dm-delay behaves like linear for flushes (Ben). - Commit message describes only the write-through case; otherwise dm stacks flush support from the underlying device (Ben). - Dropped the claim that FUA writes reach the wire: tracing the underlying disk shows a plain data write and a REQ_PREFLUSH bio. - Re-measured with write delay 0 so the timing isolates the flush class. drivers/md/dm-delay.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/md/dm-delay.c b/drivers/md/dm-delay.c index 4864671c2222f..96bb430215a32 100644 --- a/drivers/md/dm-delay.c +++ b/drivers/md/dm-delay.c @@ -301,6 +301,7 @@ static int delay_ctr(struct dm_target *ti, unsigned int argc, char **argv) } ti->num_flush_bios = 1; + ti->flush_supported = dc->flush.delay != 0; ti->num_discard_bios = 1; ti->accounts_remapped_io = true; ti->per_io_data_size = sizeof(struct dm_delay_info); @@ -451,7 +452,7 @@ static int delay_iterate_devices(struct dm_target *ti, static struct target_type delay_target = { .name = "delay", - .version = {1, 5, 0}, + .version = {1, 5, 1}, .features = DM_TARGET_PASSES_INTEGRITY | DM_TARGET_ZONED_HM, .module = THIS_MODULE, .ctr = delay_ctr, -- 2.55.0
