Hi pete, > Then there is exactly one process that every reads any configuration > file from disk. It would likely be the one mentioned in fstabs. > All the other servers are started by passing a BMI address to this > primary server process on the command line. (This is maybe not what > you had in mind.)
Sam and I had discussed this possibility and I think RobR does not wish to go down this path because every server would depend on this one particular server to get started. In the short term, it is easiest to remove the dependence on the second config file by passing in the server alias as the command line parameter and having the parsing code figure out BMI addresses, storage spaces, log file pathname etc from the fs.conf file. > You'll also need a command-line argument to specify each server's > address. A good default _could_ be chosen by the primary server > by looking at the peer name given by BMI and seeing if the hostname > part matches something in the config file. Some setups, like for > failover or for machines serving through a non-primary interface, > will need to be able to specify their own server address on the > command-line; it can't be guessed from hostname. Right; except that since we do not wish to add that initial handshaking, we will probably just pass the server's alias as command line argument. Does that sound ok to you? > I'd rather see StorageSpace and LogFile as normal tags in the > Filesystem section, then add <Server ib01> ... </Server> as a > way to override any particular setting, like in ssh_config, e.g. > Most central setups will use similar pathnames on each machine. > But this is only a slight preference. Okay. Makes sense. > > (And your "localhost1" etc. must be server aliases, not hostnames.) Right.. My bad. > > > NOTE: each server maintains a global in-memory session identifier that is > > propagated by the putconfig() from the root-server and this identifier > > is part of every client servreq structure. If it matches with the server > > id, the requests are processed, else the clients are forced to do a > > getconfig(). > > That's a nice addition. Can you use the hash value of the config > file itself? That's true. We could just pass that around instead of maintaining a separate session identifier. I will try to put together a patch for eliminating the second config file and support for SIGHUP handling. thanks for the comments! Murali _______________________________________________ Pvfs2-developers mailing list Pvfs2-developers@beowulf-underground.org http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
