dm-delay parses and reports a flush delay class (the 9-argument table form's <flush_device> <flush_offset> <flush_delay>), delay_map() routes REQ_PREFLUSH bios to it, the target sets num_flush_bios = 1, and Documentation/admin-guide/device-mapper/delay.rst documents flush delays. But the target never sets ti->flush_supported, so dm_table_supports_flush() is false: the block layer strips REQ_PREFLUSH as a no-op before the bio ever reaches the target (blk_insert_flush()), REQ_FUA is stripped too, and the flush delay class is dead code. Anyone who configures a flush delay on dm-delay (e.g. to model slow-flush devices in tests) silently measures nothing.
Set ti->flush_supported = true so the flush delay class is actually reachable. dm core clones empty flushes with REQ_OP_WRITE | REQ_PREFLUSH | REQ_SYNC (__send_empty_flush), which delay_map() already routes to the flush class, and delayed completion is already handled for every class by the delay worker. Verified with dm-delay over a virtio-scsi disk: without this change REQ_PREFLUSH completes immediately and REQ_FUA writes are stripped by the block layer; with it, flushes take the configured delay and FUA writes reach the wire (measured as device-time per MB at D_f = 200 ms and 800 ms flush delays). Signed-off-by: Matthias Goergens <[email protected]> --- 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 --- a/drivers/md/dm-delay.c +++ b/drivers/md/dm-delay.c @@ -301,6 +301,7 @@ } ti->num_flush_bios = 1; + ti->flush_supported = true; 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 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,
