On 13 Apr 2016, at 16:26, Eric Blake <eblake@...696...> wrote: >> Having thought a bit more about this, I think we might (after all) >> need a client flag which says "I respect minimum block sizes" >> or "I respect block sizes" very early on in the negotiation. >> >> The reason why is this. >> >> Let's suppose I have a file backed NBD server. I'd really like >> to open my files with O_DIRECT in order to gain performance, but >> to do so I need to (a) advertise a minimum block size of 4096, >> and (b) (crucially) know the client will respect that. If >> my client doesn't tell me that, I'd open without O_DIRECT. >> >> Thoughts? > > Is it plausible that block sizes may differ per-export, or is it more > likely to always be a global property of the server? In other words, > should we have a dedicated NBD_OPT_BLOCK_SIZE issued by the client which > returns the sizes used globally by the server, rather than having to > advertise (possibly-separate) sizing per export? It's not only possible, it's certain. My server (for instance) supports a Ceph backend and a file backend, and they have different minimum block sizes. In the future it will also support O_DIRECT file, and that will have another block size. I suspect nbd-server.c might be like with one of the weird cow or treefile settings that I've never understood :-) However, I think it's reasonable to say a *client* either understands the concept of minimum block sizes, or does not (which is what I was getting at). -- Alex Bligh
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail