Re: [Nbd] Question about the expected behaviour of nbd-server for async ops

[Wouter Verhelst <w@...112...>]

On Sun, May 29, 2011 at 04:03:18PM +0200, Goswin von Brederlow wrote:
> Alex Bligh <alex@...872...> writes:
> 
> > Goswin,
> >
> >> But since all requests are done synchronously there are no pending
> >> requests and closing the socket is all there is left to do. So currently
> >> that behaviour is as it should be.
> >
> > I'm not sure what you mean by "synchronously". The current client issues
> > requests and processes replies asynchronously, i.e. there may be more
> > than one outstanding.
> 
> The server doesn't, currently. So it will have replied to all requests
> before it reads the NBD_CMD_DISC.
> 
> > It happens that an exception is made for NBD_CMD_DISC, certainly
> > when accessed by a filing system, because prior to unmounting it
> > waits until the disk queues are flushed.
> >
> > However, if (for instance) you do an "nbd-client -d" whilst running
> > a raw dd, then there might be an in-flight reply; if there's not,
> > its only because of synchronisation at the bio layer.
> 
> If the server where asynchronous then yes. Now there might be an
> in-flight request but it will be completed before the server dies. And I
> believe that behaviour should remain.
> 
> >> Here is what i think should happen:
> >> - on recieving a NBD_CMD_DISC request you shutdown(fd, SHUT_RD)
> >> - process and reply any pending requests
> >> - fsync() /* implicit flush, just to be nice */
> >> - shutdown(fd, SHUT_WR)
> >> - close(fd)
> >> - exit()
> >
> > That alone doesn't help (I am not sure we do the shutdown but
> > it might be an improvement). The issue is that there may be
> > replies in the tcp channel which the client has not read when
> > it hits close. I don't think shutdown blocks until everything
> > is sent, does it?
> 
> It (or close) blocks with SO_LINGER set or goes into background
> otherwise. Also lingering is allways done on exit.
> 
> >From all google can find me the kernel will still try to send any
> remaining data in the outgoing socket buffer till the SO_LINGER timeout
> or tcp timeout kills the socket for good. There seem to be no way to
> "wait for all data to be send" on a socket prior to closing it.

Of course not. Otherwise you could open a socket, perform a huge
request, and ignore whatever the server sends (i.e., by not even ACKing
the data). That would DoS the server.

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a