[DRBD-user] Stale NFS file handle vs. NFS-Server-README.txt

Lars Ellenberg l.g.e at web.de
Wed Jun 9 10:16:44 CEST 2004

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.

/ 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 ...


More information about the drbd-user mailing list