On Mon, Sep 26, 2011 at 12:11:44PM -0400, Christian Jaeger wrote: > 2011/9/26 Wouter Verhelst <[email protected]>: > > However, I fail to see why this would be useful; what's so wrong with a > > configuration file? > > As I've described, the way I want to use it is to just do one call of > a program (script) on the client computer, like > "give-me-this-path-as-an-ndb-device-path myserver:/foo/bar.img".
Well, you're still going to need some sort of configuration to be able to do that -- otherwise any person could mount any random file on your server, which is not a terribly bright idea. As I've said, you can already use nbd-server in command-line mode, which does not require a configuration file (just specify '-C /dev/null' to have it not use the default config file, if you want to try that). This mode is somewhat limited, but that can't be helped. But it's a server, and therefore by definition it's going to be doing things for clients. You can't have a server do any random thing which any random client asks you about, that's a terribly bad idea. So there needs to be some sort of configuration limiting what the sysadmin wants it to do or not to do. There's no way around that. > If a configuration file on the server is needed for this, this program > would have to create it on the fly then delete it, which is of course > doable, but IIRC currently it even needs multiple files (at least one > with the allowed IPs, too), No, that's not true; the authorization file is fully optional. [...] > > Yeah, that bit is a bit painful currently. A few years back I suggested > > to Paul that he implement some scheme whereby there would be an > > 'nbd master' device node on which you could ask for a /dev/nbdX node to > > be allocated, but I don't think anything has come from it. > > > > I could imagine a scheme whereby nbd-client checks for > > /sys/block/nbdX/pid, but that's going to be racy so would need some > > locking; this could get pretty ugly. > > What happens if the client simply tries a device (after first checking > in /sys/block/... whether it should be free) without locking, wouldn't > it get an error? Good point. Not sure, to be honest. > In case of error, just retry with the next free device? That might work, but it's still rather racy. > > Indeed. I don't think that [hashing w/o encryption] would buy us much. > > I'm not decided yet, since I haven't got real numbers yet. If the > hashing costs are low enough to run a client per core (at least on a > little faster CPU than my Atom) and not slow down remote access to a > fast hard drive (and full encryption is 3 times slower or worse), that > would seem quite interesting to me. Mmm. Yes, well, patches would probably be welcome, but I won't implement that myself. -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ Nbd-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nbd-general
