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