[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Nbd] Thoughts re INFO/BLOCKSIZE



On 04/25/2016 03:13 AM, Alex Bligh wrote:
> Over the weekend I had some thoughts about BLOCKSIZE.
> 
> I want my server to be able to know if the client respects BLOCKSIZE constraints. If it does, I can make certain optimisations (an obvious one is opening with O_DIRECT as I know every request will be page aligned). As it happens that's not the only one.
> 
> Currently we code for doing this using NBD_OPT_BLOCKSIZE.

Well, NBD_OPT_BLOCK_SIZE as currently spelled.

> Sending NBD_OPT_BLOCKSIZE means the client knows about and will
respect block sizes.
> 
> However, INFO and BLOCKSIZE are part of the same extension (though Eric mentioned splitting them).

In my qemu implementation, I did NBD_OPT_GO as a separate commit from
NBD_OPT_BLOCK_SIZE; but the two were closely enough related that I was
able to get them both in the same series, so I'm no longer strongly
leaning towards a split now that I've actually done the implementation.
(That is, before I posted my patches, I was 60:40 in favor of the split,
because block sizes added even more complications and I want to get
NBD_OPT_GO promoted to stable; but after my patches, I'm now 60:40 on
keeping them associated as the work was not that much harder, and as you
point out keeping them associated simplifies the overall spec).

> I think it would simplify matters greatly if we simply said 'if you send INFO, you are deemed to understand and respect any BLOCKSIZE information that is sent back, and if you don't like it you can terminate the connection'. This would remove the NBD_OPT_BLOCKSIZE option.

It would also eliminate NBD_REP_ERR_BLOCK_SIZE_REQD.

> This would not prevent out-of-band provision of BLOCKSIZE information, just say that if it's provided inband that takes priority.
> 
> Thoughts?

It seems reasonable to me.  Should one of us propose a followup patch to
the extension-info branch with the simplification?

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: