freebsd stable - Dec 2014 - NFS negative name caching and amd

We're struggling with an NFS negative name caching issue that results in
a file created by an NFS client 'A' being invisible on client
'B' for up
to client A's negnametimeo value.  In our scenario, a process on client
A creates a file, and passes a message to another process which may 
run on client B.  The second process expects the file created by A to
be available.

We're running a mix of 9-stable and 10-stable machines, and the problem is 
common to both.

The obvious fix is to set the nfs mount option 'negnametimeo' to 0, but 
unfortunately we also have 'amd' in the picture (which we also need in
our
environment). Amd doesn't understand negnametimeo and ignores it, leaving
it set to the system default of 60 seconds (as shown by nfsstat -m).

We have a workaround that involves adding this entry to /sys/conf/options:
NFS_DEFAULT_NAMETIMEO	opt_nfs.h

and then setting it in our kernel config file:
option  NFS_DEFAULT_NEGNAMETIMEO=0

which changes the system default to disable NFS's negative name caching.
This seemed far easier than hacking on amd :-(

Is there a better solution to this issue?  If not, would a friendly committer 
be able to add the NFS_DEFAULT_NAMETIMEO to /sys/conf/options and MFC it 
back to the 9 branch please?  I will submit a PR if that is appropriate.

Regards

--
Richard Perini

On Sunday, December 21, 2014 5:27:46 am Richard Perini
wrote:
> 
> We're struggling with an NFS negative name caching issue that results
in
> a file created by an NFS client 'A' being invisible on client
'B' for up
> to client A's negnametimeo value.  In our scenario, a process on client
> A creates a file, and passes a message to another process which may 
> run on client B.  The second process expects the file created by A to
> be available.
Which NFS server are you using?  If it is a FreeBSD NFS server, try changing
vfs.timestamp_precision to 2 (or 3) and seeing if that reduces the amount of
time you have to wait until the directory's ac timeout.

Another possible the fix is to be careful to not open the file until you know
it exists if you still want to keep the reduced LOOKUP RPC load from caching
negative lookups.
> We're running a mix of 9-stable and 10-stable machines, and the problem
is
> common to both.
> 
> The obvious fix is to set the nfs mount option 'negnametimeo' to 0,
but
> unfortunately we also have 'amd' in the picture (which we also need
in our
> environment). Amd doesn't understand negnametimeo and ignores it,
leaving
> it set to the system default of 60 seconds (as shown by nfsstat -m).
Have you tried autofs for 10-stable?  Is it able to pass this option to NFS
if you use it?  If that works, I would prefer that to be the long term
solution for this.  I'm not a huge fan of adding kernel options to override
each NFS default mount option if we can help it.

-- 
John Baldwin