On 11/22/2016 05:45 AM, Kevin Wolf wrote: >> >> Is it worth adding assert(!flags)? For now, the block layer doesn't >> have any defined flags (and if it did, we'd probably want to add a >> .supported_read_flags to parallel the existing .supported_write_flags). > > I don't think we need to assert this, no other driver does that. We have > .supported_write_flags and I would indeed add .supported_read_flags > if/when we start using flags for read requests, so we can be reasonably > sure that only those flags are set even without asserting it.
Seems reasonable. > >> [Huh - side thought: right now, we don't have any defined semantics for >> BDRV_REQUEST_FUA on reads (although we modeled it in part after SCSI, >> which does have it defined for reads). But quorum rewrites on read >> might be an interesting application of where we can trigger a write >> during reads, and where we may want to guarantee FUA semantics on those >> writes, thus making a potentially plausible use of the flag on read] > > Makes sense to me, but that's something for a different series. And > actually, I'm not sure who would even send a read with FUA set today. > Can this even happen yet? Our iscsi backend has to emulate guests that send FUA on a SCSI read command (since the SCSI spec has defined semantics for it); right now, it does that by ignoring the flag (if I read the code correctly). The NBD spec also says that clients MAY send FUA on any command including read, but that the server MAY ignore FUA on all but writes. Our NBD client code used to send the FUA bit on flush (but not read), but I ripped that out in a89ef0c. So yeah, it's definitely something for a different series, if ever. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
