Re: [PATCH] virtio-blk: Add a VIRTIO_BLK_T_OUT_FUA request type
Alberto Faria <[email protected]>
| Newsgroups | dev.linux.lists.virtio-comment |
|---|---|
| Message-ID | <CAELaAXyD9EEu2p0W1U8=QCRj1G++E5Kzpc4__u=M=VKDPVpnZA@mail.gmail.com> |
On Wed, May 7, 2025 at 8:40 PM Daniel Verkamp <[email protected]> wrote: > On Wed, May 7, 2025 at 8:30 AM Alberto Faria <[email protected]> wrote: > > > > This is a variant of the VIRTIO_BLK_T_OUT request type that further > > ensures the write becomes stable once the request completes, commonly > > known as a Force Unit Access (FUA) request. > > > > Also add a VIRTIO_BLK_F_OUT_FUA feature bit signaling support for this > > request type. > > How does this interact with the writeback field? Presumably the value > of writeback is ignored by FUA commands, but it would be good to make > that explicit. That was the intention, yes. I'll make it explicit. > Also, the device requirements "write is considered volatile when it is > submitted"/"write becomes stable" section seems like it should be > updated to include FUA requests. I added a fourth item to the list that follows those words: +\item\label{item:flush4} the write was performed using a VIRTIO_BLK_T_OUT_FUA + request. That felt the cleanest to me. > [...] > > > > +Drivers SHOULD NOT negotiate VIRTIO_BLK_F_OUT_FUA if they are incapable of > > +sending VIRTIO_BLK_T_OUT_FUA commands. > > What harm would be caused if a driver accepts the FUA feature bit but > never sends a FUA command? There's a similar sentence for VIRTIO_BLK_F_FLUSH, so I followed the precedent, but I don't think there's any need for it for FUA. I'll drop it. Thanks, Alberto > Thanks, > -- Daniel >