Sam,
That's true. The multiple servers per node stuff was added to genconfig just for debugging. I can't think of any good uses for that in practice. Are there? If not, we might be able to get away with just using a -p <port> argument in cases where multiple servers/ host is desired.
If a single node has multiple cpus and multiple disks, it may not be a bad idea to run multiple server processes on it.. I guess the alias is in some ways a succint abbreviation of what host, port and interface a server process is designed to run on, no?
Maybe its not a big deal -- and we make people change their scripts and config files. That's certainly easier/cleaner.
Indeed :)
This is an interesting idea, and allows us to leverage infrastructure that's already on most systems. It seems just as easy though to give each server a master endpoint to send his host,port,etc. config info there. That avoids a tcp/ip and portmapper dependency doesn't it? There's a startup issue, but servers could retry until they succeed.
yep; definitely. The only problem with this approach is that we don't have a standardized port number on which to query on.. Hold on.. Sigh..actually I now realize why I hadnt ventured on this track originally. We could have multiple server processes on the same physical node and we cannot do the standard master endpoint port technique or the portmapper technique since portmapper cannot deal with multiple ephemeral ports for a single RPC program number.. We could do the following trick for the multiple server case on same node.. Have a range of program numbers that are typically unallocated on a regular Linux distro and keep retrying until some program number <-> port registration succeeds. The admin tool will scan for port numbers on a set of machines for the program number ranges and push the config file information and alias information.. I think it is all getting a little handwavy without any prototype.. What do you guys think?
It also alleviates the need to have an admin tool that queries all the portmappers on all the hosts for all the server ports, and pushes that info back to all the servers.
This is not that big a deal, is it? I am trying to understand how we can make it zero-conf without telling the system something :) thanks, Murali
-sam > thanks, > Murali > >> >> -sam >> >> > thanks, >> > Murali >> > >> > On 6/19/07, Sam Lang <[EMAIL PROTECTED]> wrote: >> >> >> >> Hi Murali, >> >> >> >> Just never got around to commit it. My only complaint is that it >> >> doesn't allow the server to optionally take a server config >> file (for >> >> legacy scripts, etc.). I think that might be hard to implement >> >> though... >> >> >> >> -sam >> >> >> >> On Jun 20, 2007, at 1:19 AM, Murali Vilayannur wrote: >> >> >> >> > Hey Sam, >> >> > Any interest in merging this patch to unify config files while >> >> > starting up pvfs2 servers? >> >> > I have reworked it against HEAD.. >> >> > Relevant thread.. >> >> > http://www.beowulf-underground.org/pipermail/pvfs2-developers/ >> 2007- >> >> > February/003209.html >> >> > thanks, >> >> > Murali >> >> > <unify-config-files.patch> >> >> >> >> >> > >> >> >
_______________________________________________ Pvfs2-developers mailing list [email protected] http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
