Re: [Nbd] [PATCH] Further tidy-up on block status

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

> On 27 Dec 2016, at 14:09, Vladimir Sementsov-Ogievskiy <vsementsov@...2723...9...> wrote:
> 
> What was the reason for it? Why not to negotiate forced structured read separately? Actually, this spec forces any server, which wants to implement structured reply implement structured read too. But what if it don't want to? If it only wants to implement BLOCK_STATUS?
> 
> So, what about changing it, to allow BLOCK_STATUS (or other future structured replies) without structured read? Structured read is good only for sparse formats, when BLOCK_STATUS is more global. I understand, that servers may implement simple (and useless) one-chunk structured read, but I think that it is better to fix the spec, to not provoke servers use such workaround.

In essence the current reply format is broken, because it does not provide a means of delivering an error mid reply AND expects fixed length replies. Block Status is the poster child for something that benefits from structured replies.

So, BLOCK_STATUS requires structured replies. We thus have the choice between:
* Allowing structured replies to be implemented on a per-command basis
* Mandating that if structured replies are implemented, they are implemented universally

The second option is far simpler, and is what the current structured reply extension sets out. It's also a good nudge to server implementers (me included) to implement structured replies.

Your assumption that structured replies are only good for sparse formats is incorrect. It's good for anything that wants to include sensible error handling. As a server author, error handling at the moment is a pain. Most of us ALREADY break up large read requests (to avoid malloc() of huge amounts of memory), so we already have a read loop. If we don't then the 'one chunk' method is perfectly acceptable. If I implemented structured replies at all, I'd be sharing the code between multiple users in any case.

-- 
Alex Bligh