Brief background: We have a management product that can manage a 
Linux-based NFS server to allocate and export storage to managed 
servers.  (Then automatically mount the storage on those servers so it 
can be used)

I was seeing a problem where sometimes the directory I was exporting 
would not be mountable on the server it was exported to.

 From the server machine's /var/log/messages:

Mar 1 10:49:53 fedora3 rpc.mountd: refused mount request from 
172.31.183.2 for /mnt/NAS/exports/Levanta-1109702993-18 (/): not exported

But according to exportfs:

[root@fedora3 ~]# exportfs
/mnt/NAS/exports/Levanta-1109702992-17
172.31.183.2
/mnt/NAS/exports/Levanta-1109702993-18
172.31.183.2
/mnt/NAS/exports/Levanta-0
172.31.183.2

After some debugging:

It looks like exportfs updates /var/lib/nfs/etab to inform mountd that 
there are new exports.

mountd decides whether to re-read etab based on whether the data 
modification time has changed since etab was last read.  This fails if 
there are multiple updates in a second - quite possible on fast new 
machines if the NFS server is being programmatically controlled.  This 
patch updates mountd to track when it actually read the file, and 
compare that with the file's modification time.  If it last read the 
file at the same time it was last modified, re-read the file again in 
case there were other modifications later that second.  (Strictly 
speaking, the modification time equality check isn't necessary... only 
comparing the modification time to the last read time, but I guess isn't 
a bad idea as added protection against someone playing with the clock).

-Nate

(I'd sent this once before, but wasn't a member of the list and it seems 
to have been eaten ;-P, so I apologize if the first copy eventually made 
it though and this is a duplicate)