[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. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature