Hi Phil, Rob, I should have responded to your questions earlier. So here's what Sam and I had in mind. A SIGHUP (or a tool that does something equivalent) will cause all servers to restart without actually exiting. We envision a full server restart. However, the pid's wont change. We expect that admins will change the fs.conf file settings, propagate it to all machines, and use this tool to send a SIGHUP to all servers which will cause them to close all fd's and reread configs before listening for connections again. NOTE: If admins do not keep all the files uptodate, the pvfs2-ping tool will verify if they missed this step or not.
In order to let the clients figure out that they need to reissue a getconfig(), the servers keep an in-memory session identifier (Pete's suggestion was that we could keep a SHA1 digest of the fs.conf file itself which will allow all servers to regenerate the same session identifier assuming they all see identical fs.conf content!). All requests sent to the server will now have the sha1 digest embedded in them which is then compared with the server's digest. Upon a mismatch, servers will NACK client requests and this will cause clients to reissue a getconfig and reload their config information. Hopefully that explains what we had in mind a little bit better. This is still a work-in-progress and I am not sure I will have the implementation ready before I leave. Thanks, Murali >> snipped << Ok- just kinda checking to make sure of what you guys had in mind. If the HUP is a full restart of the server, then it will complain on its own if the config file doesn't match what's in the storage space, so that isn't really a danger. It also means that pretty much any tuning parameter is legal to change since all of the I/O components will be starting from scratch. Just a heads up on one detail- we need to make sure that the server keeps its pid on the HUP or else updates its pidfile so that monitoring scripts don't get confused. I think that leaving the client configuration alone is fine. -Phil Rob Ross wrote: > I feel like the HUP should be a full server restart? > > Clients don't have a way to know that they need to reload the config > file, currently. Likewise, since someone could just kill the server and > then restart with a totally different config file, I don't think that we > want to try to enforce any rules on what parameters may be changed. This > is just a convenient way to reload, right? > > Rob > > Phil Carns wrote: > >> I have a few questions about some details of the implementation: >> >> - What exactly will a HUP do on the server side? For example, is this >> pretty much a full server restart, a restart of the I/O components >> (job/trove/bmi/etc.), or just selectively reseting parameters that can >> be changed dynamically? >> >> - How will a reload of the configuration affect clients that already >> have the file system mounted? They typically have already read and >> parsed the configuration locally. Do they continue with the previous >> configuration or do they get the updates as well? >> >> - This sort of depends on the answers to the previous questions, but >> is there any restriction on what configuration parameters can actually >> be changed on the fly? There are some obvious ones that cannot be >> changed (fsid, root handle, range ownership, etc.). Are there any >> others? Do we need anything to protect against this or just document >> what parameters are off limits? >> >> >> FWIW, I agree with the direction that you guys are now heading with >> this stuff for the near future. The dependence on a particular >> servers being around for startup and use of things like portmapper >> would cause problems for our environment. We have to worry a good bit >> about firewalls, and asymmetric servers would make it harder to play >> nice with failover software. >> >> -Phil _______________________________________________ Pvfs2-developers mailing list [email protected] http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
