[PATCH] dm-delay: advertise flush support

[PATCH] dm-delay: advertise flush support

[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,

Re: [PATCH] dm-delay: advertise flush support

[Benjamin Marzinski]

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,

Re: [PATCH] dm-delay: advertise flush support

[Benjamin Marzinski]

On Fri, Aug 14, 2026 at 03:35:25PM -0400, Benjamin Marzinski wrote:
> 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".
>

Actually, it might be better to only set ti->flush_supported if
dc->flush.delay is non-zero, so that if the user doesn't want a
flush delay, dm-delay behaves like a linear target for flushes.

-Ben

> -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,

[PATCH v2] dm-delay: advertise flush support when a flush delay is configured

[Matthias Goergens]

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 <bmarzins@redhat.com>
Signed-off-by: Matthias Goergens <matthias.goergens@gmail.com>
---
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

Re: [PATCH v2] dm-delay: advertise flush support when a flush delay is configured

[Mikulas Patocka]

OK.

I updated the patch in the linux-dm repository.

Mikulas



On Thu, 17 Sep 2026, Matthias Goergens wrote:

> 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 <bmarzins@redhat.com>
> Signed-off-by: Matthias Goergens <matthias.goergens@gmail.com>
> ---
> 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
>