dm-delay: advertise flush support

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>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>

0 files changed, 0 insertions, 0 deletions