Re: [Nbd] [PATCHv6] Remove NBD_OPT_BLOCK_SIZE; add specific requests to NBD_OPT_INFO

[Alex B. <al...@al...>]

Eric,

On 29 Apr 2016, at 16:43, Eric Blake <eb...@re...> wrote:
>> 
>> 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.

In which case your choice is doubly reasonable!

In gonbdserver the main effect of the preferred block size is
memory efficiency. Stuff smaller than that wastes memory (more
precisely each allocation is always the size of the preferred
block size or multiples thereof).

>> 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 :)

I don't think it actually is out-of-band because it affects what
is passed inband.

>  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.

Yeah

>  And a choice of whether
> to use O_DIRECT might also be, to some extent, and out-of-band
> configuration.

Well the configuration would be out of band, but I can see a server
might select O_DIRECT operation on the basis of whether the client
actually understood 'I can only do page size I/O'.

>  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.

Indeed. I'm off to fix up gonbdserver to comply with the new spec now.
Ping me when you have qemu working and we can do some interoperability
testing.

--
Alex Bligh