[BBLISA] Summary of responses Re: NFS: How can I see which files are in use?

[Dean Anderson]

NFS is stateless. At the server, the inode layer is accessed directly by
the NFS kernel thread, using the file handle (fs, fileno) and offset
information from the packet. There are no open file structures for tools
like lsof to find.  I think if you look at the code in the NFS server,
an open just checks to see if the file exists and the permissions, and
returns this to the client.  An nfs unlink renames the file, so that the
client can still access the open, unlinked file. But if you locally
delete the file, the nfs client just loses.  (that situation is known as
a 'violation of unix file semantics' and one of the objectives in OSF
DFS was to always maintain unix file semantics. AFS maintains unlinking 
semantics, but not locking. NFS sort of gets locking with lockd, but 
lockd is stateful, and doesn't maintain state across reboots. So, you 
see, the devil is in the details. ;)

Packet sniffers can probably find out what files are being accessed, if
those files are accessed while the sniffer is running. But as NFS is
stateless, and the server and sniffer may be rebooted while a file is
open, and who knows how long it might take for an open file to be read,
written, etc by a client.  The error log of an apache virtual host might
be open for hundreds of days, but never accessed.

The object (pun!) of stateless file service is to make it unnecessary to
know what files are open (which is state=open).  If the server is down,
the client waits uninterruptibly until the server comes back up, and
continues as if nothing happened (the big advantage of statelessness).

This stateless (wait forever when down) behavior has been somewhat
modified, as many people don't like their workstations hanging on down
nfs fileservers, but still want their builds to wait transparently
across a server reboot.  Several vendors did different things with hard
and soft mounts. The one I like best was the OSF 'spongy' mount, in
which a directory access would timeout and be unmounted, while a file
access would wait forever.

By contrast, stateful services like AFS and DFS immediately know when
the server crashes, and timeout, which is great for path searches, but
horrible for builds (e.g. the make program may think a big part of the
object tree is empty and start trying to remake those objects--doh) DFS
waits forever, but is interruptible, if I recall.  DFS is a great system
but is so complicated that only a few people on the planet know how it
works, and some think they are probably lying about what they know.

Don't get me started on SMB. Course, SMB is a toy system, so who cares
;-) ;-) :-P :-P

		--Dean

On Tue, 19 May 2009, Dewey Sasser wrote:

> Dewey Sasser wrote:
> > I would like to be able to see, from my NFS server, which files are in
> > use by NFS clients.
> > ...
> >   
> The summary of responses was, in effect:  there is no way to do it on a
> general Linux system.
> 
> Several people pointed out places where documentation (e.g. lsof)
> implies this should be doable, but experimentally it works for NFS
> clients but not servers.  One person reported success with a home-grown
> pcap library based traffic sniffer but did not say the source was
> publicly available.  Several others suggested packet sniffers, one
> person suggested using "systemtap" to build one.
> 
> One response indicated that on the Sun Fishworks storage box (e.g. 7210)
> this information is trivially available.
> 
> Thanks for all responses.
> 
> --
> Dewey
> 
> _______________________________________________
> bblisa mailing list
> bblisa at bblisa.org
> http://www.bblisa.org/mailman/listinfo/bblisa
> 
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000