* [PATCH] dm-delay: advertise flush support
@ 2026-08-14 4:58 Matthias Goergens
2026-08-14 19:35 ` Benjamin Marzinski
0 siblings, 1 reply; 2+ messages in thread
From: Matthias Goergens @ 2026-08-14 4:58 UTC (permalink / raw)
To: dm-devel
Cc: agk, snitzer, mpatocka, bmarzins, linux-kernel, Matthias Goergens
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 <matthias.goergens@gmail.com>
---
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,
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PATCH] dm-delay: advertise flush support
2026-08-14 4:58 [PATCH] dm-delay: advertise flush support Matthias Goergens
@ 2026-08-14 19:35 ` Benjamin Marzinski
0 siblings, 0 replies; 2+ messages in thread
From: Benjamin Marzinski @ 2026-08-14 19:35 UTC (permalink / raw)
To: Matthias Goergens; +Cc: dm-devel, agk, snitzer, mpatocka, linux-kernel
On Fri, Aug 14, 2026 at 12:58:12PM +0800, Matthias Goergens wrote:
> 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).
>
The code seems fine, but could you please change the commit message.
It's not true that "Anyone who configures a flush delay on dm-delay
silently measures nothing". dm-delay doesn't *force* the dm device to
support flushes. It works just like most of the dm targets: linear,
stripe, raid, etc. If an underlying device sets BLK_FEAT_WRITE_CACHE or
BLK_FEAT_FUA, the dm device will as well (see blk_stack_limits, called
by dm_set_device_limits). I assume if you look at
/sys/block/<underlying_disk>/queue/write_cache, you see "write through".
-Ben
> Signed-off-by: Matthias Goergens <matthias.goergens@gmail.com>
> ---
> 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,
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-08-14 19:35 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-08-14 4:58 [PATCH] dm-delay: advertise flush support Matthias Goergens
2026-08-14 19:35 ` Benjamin Marzinski
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox