Re: [Qemu-devel] NBD block device backend - 'improvements'

[Nicholas Thomas <nick@bytemark.co.uk>]

Hi Kevin, Stefan.

On Tue, 2011-02-15 at 12:09 +0100, Kevin Wolf wrote:
> Am 14.02.2011 21:32, schrieb Stefan Hajnoczi:
[...]
> > block/nbd.c needs to be made asynchronous in order for this change to
> > work.  
> 
> And even then it's not free of problem: For example qemu_aio_flush()
> will hang. We're having all kinds of fun with NFS servers that go away
> and let requests hang indefinitely.
> 
> So maybe what we should add is a timeout option which defaults to 0
> (fail immediately, like today)

Noted, so long as we can have -1 as "forever". I'm currently spending
time reworking block/nbd.c to be asynchronous, following the model in
block/sheepdog.c

There does seem to be a lot of scope for code duplication (setting up
the TCP connection, taking it down, the mechanics of actually reading /
writing bytes using the aio interface, etc) between the two, and
presumably for rbd as well. 

Reading http://www.mail-archive.com/qemu-devel@nongnu.org/msg36479.html
suggests it should be possible to have a "tcp" (+ "unix") protocol /
transport, which nbd+sheepdog could stack on top of (curl+rbd seem to
depend on their own libraries for managing the TCP part of the
connection).

They would implement talking the actual protocol, while the tcp/unix
transports would have the duplicatable bits.

I've not investigated it in code yet - it's possible I'm just letting my
appetite for abstraction get away with me. Thoughts?

> Unconditionally stopping the VM from a block driver sounds wrong to me.
> If you want to have this behaviour, the block driver should return an
> error and you should use werror=stop.

Unconditional? - if the socket manages to re-establish, the process
continues on its way (I guess we'd see the same behaviour if a send/recv
happened to take an unconscionably long time with the current code).

Making just the I/O hang until the network comes back, keeping guest
execution and qemu monitor working, is obviously better than that
(although not /strictly/ necessary for our particular use case), so I
hope to be able to offer an AIO NBD patch for review "soon". 

> > IPv6 would be nice and if you can consolidate that in qemu_socket.h,
> > then that's a win for non-nbd socket users too.
> 
> Agreed.

We'd get it for free with a unified TCP transport, as described above
(sheepdog already uses getaddrinfo and friends) - but if that's not
feasible, I'll be happy to supply a patch just for this. Much easier
than aio! :)

/Nick