Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Todd Denniston wrote: > Raoul Borenius wrote: > <SNIP> >> Here ist my haresources with only one data-volume: >> >> b1 drbddisk::varlibnfs \ >> drbddisk::mail \ >> Filesystem::/dev/drbd0::/var/lib/nfs::ext3 \ >> Filesystem::/dev/drbd1::/srv/nfs/mail::ext3 \ >> killnfsd \ >> nfs-common \ >> nfs-kernel-server \ >> sleep::3 \ >> IPaddr::194.95.249.20/24/eth0 >> >> >>> If it looks like the drbd failover worked, that is, the /var/lib/nfs >>> symlink was pointed to drbd0, and drbd0 was there before nfs >>> started.. it >>> may be something else that is causing stales during failover. >> >> > > > Just for clarification: > You indicate you use a softlink to put the drbd0 filesystem in place of > /var/lib/nfs, but above you mount drbd0 at /var/lib/nfs ... which is it, > and is it the same on BOTH systems? > > I have several exports, from different drbd managed partitions, with a > softlink /var/lib/nfs -> /nfsstate/var/lib/nfs where nfsstate is my > drbd0 which until recently did not have problems with stale nfs ... WAIT > A MINUTE, now I know why I was seeing stale nfs handles the last time I > fell over: after doing an `ls -l /var/lib/nfs`, I see that for some > reason the systems have blown away my softlinks and replaced with new > boot disk resident directories, must fix. Thanks for the wake up. > Just in case some one else ends up seeing this problem. What happened was that when I updated to a new nfs-utils rpm in June, it overwrote the /var/lib/nfs structure. So if you use the softlink method keep an eye out for nfs rpm updates. :}