Alex Bligh <[email protected]> writes:
> The first option the client sends (not the last) should be the
> export name, because that's what you need to return things like
> size.
My plan is to use NBD in a dynamic setup even with hotplug support.
That means I won't exactly know what disk will be available in the
server. So I need a "list exports" option for that to work well.
Obviously I can't send an export name prior to list exports.
I wouldn't say that any option must be first. I would just say that some
options must be after others.
There are several implementations already of nbd so I think one more
thing should be considered from the start. Those implementation might
want to do their own little things. Try things out before getting them
added to the protocol as standard. There should be one defined option to
exchange client/server name and versions and whatever other private
information they need to share and a range of options reserved for
client/server specific and experimental use. Those options would only be
valid between client/server of the same implementation.
The reason why they should be pre-allocated is so that they don't
collide with any future standard options later on.
MfG
Goswin
------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
Nbd-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/nbd-general