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