Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
crosspost to linux-ha, maybe this thread should continue there. guys, to have the context, you could have a look in the drbd list archives, e.g. http://thread.gmane.org/gmane.linux.network.drbd/6745 / 2004-06-09 09:38:50 +0200 \ Weyer, Wolfram: > Jens, > I had similar problems in a different HA environment (no heartbeat!), > however the mechanisms should be the same. In this first approach I used > ifconfig to control the IP address and exportfs to control the nfs export. > Removing the export immediately after the ifconfig to remove the IP address > returns, leads to these "Stale NFS file handle problems". I three second > delay solved this but significantly slows down the failover time. > This somehow points to an asynchronous behavior of ifconfig, meaning that > there is some traffic on this IP address even the ifconfig already shutdown > the interface. > Following some "google"-hints I added an additional step by directly > blocking the nfs-port using iptables. The procedure for a graceful failover > then follows these steps: > NodeA: ifconfig down ... > iptables -D --dport 2049 ... > exportfs -u ... > NodeB: exportfs ... > iptables -A --dport 2049 ... > ifconfig up ... > Using these steps it works without delay. > > /Wolfram so the *right* thing to do seems to be to fix (un)exportfs and add some option to do what it has to do, only *not* notify its clients... though I think an unexport still does something bad with the servers (shared) lock data? but in that case, one could disable that too. someone should have a look at exportfs (and its kernel interface) so one can do exportfs -u ... --dont-notify --keep-locks ... :) lge