Janne Karhunen wrote:
I think you mis-understand our approach. With our patch, you do *not* need
to do anything if you have only one single (floating) interface to do nfs
export (and you can have the machine configured to use other hostname). The
statd's "my_name" is correctly filled (from kernel by our patch) - it is no
longer bound to 127.0.0.1.
What happens when it fails over to node that has
different name? Mon_name in NOTIFY changes
while address it's coming from does not. Which
one should client believe - the address or the
name?
But OK, I probably need to dig out the patch to
have a look.
In the middle of re-doing our old patch (it should be very small this
time, with Frank's patch already in mainline and Chuck taking over IPV6
issues) so the logic can be clear. I also have a feel that you never
look into "sm-notify" ? Get nfs-util git tree source and take a look at
the "README" file in the top directory. Either Neil Brown or Steve
Dickson had added a nice "DAEMON STARTUP ORDER" there. Basically the
whole issue is a two-steps thing:
1. statd is the process responsible for recording client address into
the nsm directory
2. sm-notify is the process responsible for notifying clients about
server reboot activities.
The "sm-notify" design allows the flexibility of notifying clients with
different cluster configurations, including yours. I think you already
know this stuff very well... just do a "man sm-notify" ... it should
clear up your confusions.
-- Wendy
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
