Hi Pete,
I was actually thinking the tabfile list would be optional, and its
use would be only to filter out addresses in the list provided for
each Alias. The BMI methods would still be enabled based on what was
specified in the BMIModules config option. This still hurts
performance because of the sequential polling with multiple methods
enabled, but I was thinking that could be solved separately (multiple
threads, etc.). Should we try to not enable methods specified in
BMIModules if they're filtered out with the mntent option?
-sam
On Nov 9, 2007, at 9:13 AM, Pete Wyckoff wrote:
[EMAIL PROTECTED] wrote on Wed, 07 Nov 2007 16:21 -0600:
I discussed the desired behavior we want out of this fail-over
code with
folks offline, and we came up with a plan.
Sorry for the delay. Head down in SC. I definitely like this plan
and believe you addressed the common cases on server and client.
Murali's ideas of protocol splitting are cool, but I think would be
too complex for now, when we just want to get something working for
failover.
The client mount option. We already have a fs.conf BMIModules that
affects server and all potential clients. You want to add a
client-specific list to its pvfs2tab that limits that. This may be
something that also should be more general. We might get into more
messes where different clients call hosts different things, and
client 27 shouldn't even try to connect to hostb as it will go over
the wrong network, or such.
But, for now, a tab-file list of bmi addresses is expedient, maybe
with an eye for a generic "fs.conf client-specific override"
mechanism in the future? I caught on this because it will be
"BMIModules" in fs.conf, but "bmi" in pvfs2tab. Would like those to
be the same.
-- Pete
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
