2003-09-29 20:20:27

by Donavan Pantke

[permalink] [raw]
Subject: GETATTR returns spurious NOENT

Hi Guys,

We have discovered an interesting behavior in the Linux knfsd server
and the client, and I need your help in figuring out how to troubleshoot
further.

We have a SuSE SLES7 server (using Mantel's 2.4.18 errata kernel)
talking to another SLES7 (also 2.4.18-based) NFS Server. The client takes
incoming files (via our own hacked as crap protocol lol), and writes them to
the NFS server. Then another thread is spawned which opens this newly written
file and begins to read it for importing into a database. This happens a
_lot_.

Since the files are being written are read right back, the data is
still being held in the read cache of the client. This is an assumption,
since there's not a whole lot of read calls going on, but GETATTR's are being
done (which I'm assuming are cache validations). When the NFS server is under
load (normally from local processes like rsync being done concurrently),
there are times when the GETATTR cache validation is getting a NOENT return
from the server. We checked to make sure that the file wan't being deleted or
something, but the client process will retry the import on the next run, and
a LOOKUP and GETATTR for the same file both succeeded and returned the same
inode numbers, so the file inode didn't change.

Now, the 2 questions that come from this are: What is causing this
spurious NOENT? And shouldn't the client either simply invalidate the cache
instead of reporting an error to the calling process, or should it return a
Bad file descriptior message. Currently, the NOENT is passed directly to the
client process, which isn't a valid return code for a read() call.

I have a packet capture of the whoel session, but it's 100M big, so I
can post a smaller subset of it, just let me know how much you all want.

Thanks!
Donavan Pantke
Network Engineer
Appriss, Inc.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs