[updating CC to point to the correct new NBD list]
On 09/21/2017 07:18 AM, Vladimir Sementsov-Ogievskiy wrote:
Hi all!
I'm about this:
"A server SHOULD try to minimize the number of chunks sent in a reply,
but MUST NOT mark a chunk as final if there is still a possibility of
detecting an error before transmission of that chunk completes"
What do we mean by "possibility"? Formally, such possibility exists
always, so, we'll never mark a chunk as final.
Here's what is envisioned. It is fairly easy to write a server that
receives an NBD_CMD_READ, issues the header reply, and only then
dispatches the I/O to collect the data from the file system to send
after the header. But if you encounter EIO (or other problem) while
reading from the file system, you're stuck if you've already sent the
header. In this scenario, if you mark the header being as final, you
are unable to report the EIO (it is one of the flaws with non-structured
reads that makes the spec say that if you detect an error after sending
the header, you have no choice but to terminate the connection).
An alternative server implementation would buffer the header, perform
the I/O to collect data from the file system, and only when it is all
present in memory, it finally sends the reply to the client. In this
scenario, since you wait until all data is buffered, you know up front
whether an error occurred while collecting the I/O, and can therefore
send the data as the final packet right away (whether error or success).
However, it potentially requires more memory to buffer requests like
this, compared to the server that sends information piecemeal as soon as
it obtains data.
The intent is not to detect errors in sending the data over the wire,
but in detecting errors in reading the data from the underlying storage
(or however else the data to be read is being collected). A chunk must
not be marked final unless you can guarantee that there will be no
further errors in collecting data for the reply.
If you have suggestions for improving the NBD spec wording, feel free to
propose a doc patch.