[Pvfs2-developers] RFC: Config file overhaul

Phil Carns pcarns at wastedcycles.org
Wed Sep 27 10:26:50 EDT 2006


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



Rob Ross wrote:
> Hi all,
> 
> Since I'm being discussed, I thought that I should chime in :).
> 
> I agree that what we're talking about here is just a couple of steps in 
> the right general direction, not where we would really like to be in the 
> long run.
> 
> The zero-conf concept sounds great to me, conceptually. However, I don't 
> want to have an implementation of that that forces us into a dependence 
> on a particular server for startup. More discussion might change my 
> mind? I dunno.
> 
> Server-to-server (s2s) seems like the right way to do the config file 
> verification in the long term. However, the code we're going to use to 
> do that is just now shaping up. So we're not quite ready to do that yet.
> 
> So, I proposed (off-line) that we do this interim thing for now (which 
> cleans things up quite a bit) and continue thinking and talking about 
> how we might like the system to work in the longer term.
> 
> Regards,
> 
> Rob
> 
> Murali Vilayannur wrote:
> 
>> Hi pete,
>>
>>> I thought with your discussion of getconfig/putconfig that you were
>>> implicitly planning to get server-to-server communication to work
>>> too.
>>
>>
>> I was planning on doing that. But it fizzled out because of RobR's 
>> concern
>> about scalability and dependence on a single root server..
>>
>>> What you describe here sounds like fine stuff.  And if later
>>> somebody gets ambitious and wants to do more "zeroconf"-ish work,
>>> they can build on this.  Thanks for the explanations.
>>
>>
>> Yep. Exactly. I hope so too :)
>> thanks!
>> Murali
>> _______________________________________________
>> Pvfs2-developers mailing list
>> Pvfs2-developers at beowulf-underground.org
>> http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
>>
> _______________________________________________
> Pvfs2-developers mailing list
> Pvfs2-developers at beowulf-underground.org
> http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers



More information about the Pvfs2-developers mailing list