On 04/29/2016 09:25 AM, Alex Bligh wrote: >> The server can always do a minimum block size of 1 (it already has code >> to do a read-modify-write, when needed), so it will never disconnect a >> client that uses NBD_OPT_EXPORT_NAME, nor will such a client ever get an >> EINVAL for an unaligned read. However, there are some files that are >> more efficient with a block size of 1 (anything on the file system) than >> others (an actual block device, where 512 or 4096 is more typical). So >> on a per-export basis, the server will prefer to advertise a minimum >> block size that matches the type of file it is serving, where possible. >> It works out to these four cases: >> > That seems perfectly legal to me, and indeed was what I was first > planning on doing. > > Then I thought of an alternative strategy. This is in essence to > always reply with a minimum block size of 1 (after all, you *can* > support it), and return a preferred block size of the block > size of the back-end. This strategy assumes the client will > respect the preferred block size at least 'most' of the time, > and also that you don't have to open the back-end in a different > manner to support block sizes smaller than the native blocksize > (e.g. you are not doing O_DIRECT type things). Except that I want the preferred size to be larger than 4096 - if I'm serving a qcow2 file, I want the preferred size to be the cluster size (often 64k, can be as small as 512 or as big as 2M depending on the qcow2 file, though), because there ARE efficiency gains once you get to the cluster level, and things like TRIM or WRITE_ZERO on a qcow2 file are constrained to the cluster size. > > FWIW gonbdserver just has a 'GetGeometry' call which returns > the block sizes the backend would like. These are mildly > sanitized (and overrideable in the config file), and then > passed through. Config file overrides count as out-of-band coordination :) And to some extent, the choice of preferred block size isn't as much of a sticking point as the choice of the minimum block size. And a choice of whether to use O_DIRECT might also be, to some extent, and out-of-band configuration. At any rate, I'm glad we agree that my reading of the spec vs. planned implementation sounds reasonable - it means the spec is on the right track. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature