Re: [Nbd] [PATCH v3 4/5] doc: Propose STRUCTURED_REPLY extension

[Alex Bligh <alex@...872...>]

On 31 Mar 2016, at 18:05, Wouter Verhelst <w@...112...> wrote:

>>>> Although I'm implementing a server at the moment where I'd like to
>>>> do just that with lengths in excess of 2^31.
> 
> Why?

Because golang represents lengths to 'read' as 'int' which is platform
dependent 32 bit or 64 bit SIGNED integer depending on platform. Offsets
are all 64 bit. I'm sure other platforms (admittedly not POSIX) may have
signed size types.

I know that in practice *lengths* > 2^31 are hardly ever used by any
client, so I'd like to say "the maximum length you can send me is
2^31 - 1". This is better than putting in a special code path (with
the possibility of introducing bugs, and which will be hard in practice
to test without 2GB of memory to spare, and 2GB on disk, which is
hard to put in unit tests) just to handle something that most clients
won't want anyway, and which they are likely to have code to fragment
themselves so they can do 64 bit length reads. That extra code path
is just an opportunity for things to go wrong.

>>> Oh, good point - particularly true if you are targeting 32-bit hardware
>>> where ssize_t limits read() and write() to 2^31 bytes in a transaction
>>> (and in that case, both CMD_READ and CMD_WRITE should consider this case).
>>> 
>>> But what do we do about Wouter's request that we not permit EOVERFLOW
>>> without structured replies being negotiated?  Does that mean that
>>> CMD_WRITE cannot reply with EOVERFLOW unless structured replies are
>>> negotiated?
>> 
>> I'm guessing EIO?
> 
> No.
> 
> Large-file support on 32 bit architectures has existed since several
> decades now. We should not cater to that; people should just write
> software that can handle LFS offsets.

It's not offsets that are the issue, it's lengths.

I'd also like to say "I'd like my offsets / lengths to be a multiple of 4k"
so I can open O_DIRECT. Or at least say "can you cope with only offsets /
lengths that are a multiple of 4k, as if so I can perform better". But
this should probably be on a different wish-list!

-- 
Alex Bligh