Re: [Nbd] NBD wishlist items?
- To: "Paul Clements" <paul.clements@...124...>
- Cc: nbd-general@lists.sourceforge.net, Wouter Verhelst <w@...112...>, ltsp-developer@lists.sourceforge.net
- Subject: Re: [Nbd] NBD wishlist items?
- From: "Mike Snitzer" <snitzer@...17...>
- Date: Tue, 26 Jun 2007 11:56:51 -0400
- Message-id: <170fa0d20706260856w7fc11d43yf93df4bff2b93120@...18...>
- In-reply-to: <46812E43.2010100@...124...>
- References: <20070618133932.GA28328@...39...> <170fa0d20706191622l226dd12dt6f212c2a1e4034b7@...18...> <20070621112317.GA6035@...39...> <467BEC91.4050105@...124...> <20070623102349.GB671@...39...> <46812E43.2010100@...124...>
On 6/26/07, Paul Clements <paul.clements@...124...> wrote:
Wouter Verhelst wrote:
> A protocol extension that lets both the server and the client initiate
> this keepalive probe would deal with both issues (provided we do not
> somehow swap out nbd-client).
Do we need the server to do this keepalive stuff, though? I mean, it's
really the client that cares if the connection goes down. The server
ought to be happy to just sit there -- if it's not getting any requests,
it shouldn't matter.
I agree, having the nbd-client do a keepalive is all that should be needed.
>>> Implementing this backwards-compatibly is going to be the hardest part,
>>> I guess. Perhaps opening one of the NBD devices to call a specific ioctl
>>> to verify whether it supports this interface, and then setting a bit in
>>> the field of 'reserved' bits in the handshake could work, but I'm not
>>> sure how this would be best done.
>> There'd probably be an ioctl to enable this ping packet, so you could
>> just call the ioctl and ignore failure (for older kernels). Then there'd
>> be a new packet flag for this ping packet (or maybe just use a
>> zero-length read or write, assuming the nbd-server just ignores those
>> and returns a response). That way it would almost completely backward
>> compatible.
>
> Sorry, I'm not sure I understand that bit. Could you elaborate?
I was just thinking out loud. Basically, an easy and backward compatible
way to do this (client-side) ping is to periodically send a zero-length
read or write, and as long as the server just ignores it (i.e., doesn't
crash or do something otherwise stupid) and sends a response, everything
will work and the protocol doesn't have to change.
How does one do a zero-length read or write? I've been testing
various userspace methods to detect the nbd-client's connection to be
hung (TCP timeout). Using dd is unreliable because the read request
is fulfilled from cache if you don't use O_DIRECT.
If we could do a zero-length write then this would very easily
excercise the nbd connection without any protocol change or O_DIRECT
reads. Can you elaborate on what is needed for reliable zero-length
writes? The 'man 2 write' states:
"If count is zero and the file descriptor refers to a regular file, 0
may be returned, or an error could be detected. For a special file,
the results are not portable."
thanks,
Mike
Reply to: