On Wed, Jun 12, 2024 at 05:56:15PM +0200, Roger Pau Monné wrote: > Right. AFAICT advertising "feature-barrier" and/or > "feature-flush-cache" could be done based on whether blkback > understand those commands, not on whether the underlying storage > supports the equivalent of them. > > Worst case we can print a warning message once about the underlying > storage failing to complete flush/barrier requests, and that data > integrity might not be guaranteed going forward, and not propagate the > error to the upper layer? > > What would be the consequence of propagating a flush error to the > upper layers? If you propage the error to the upper layer you will generate an I/O error there, which usually leads to a file system shutdown. > Given the description of the feature in the blkif header, I'm afraid > we cannot guarantee that seeing the feature exposed implies barrier or > flush support, since the request could fail at any time (or even from > the start of the disk attachment) and it would still sadly be a correct > implementation given the description of the options. Well, then we could do something like the patch below, which keeps the existing behavior, but insolates the block layer from it and removes the only user of blk_queue_write_cache from interrupt context: ---
