Subject: RE: NFS MIB ideas

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 19 Mar 2001 07:46:14 -0800

I don't know what LOCK_RT either but I understood the proposal
do be to create something that the V4 spec considers to be a
lock but is not a lock the way the word is generally used.

In V4 if I open a file, that is a lock (there is an associated
stateid, lease, etc.) in the V4 sense but since it doessn't lock 
out any other access, this would normally not be considered a lock.

We could extend that same approach to directories as a way of 
recording who has a file mounted.

The downside of this proposal is that it would mean that every
client would always have to have an active lease and keep
renewing it.  This would increase server load and inhibit the
servers from recycling data structures about inactive clients,
or rather about clients who would be inactive if they didn't
have this directory lock whose lease they kept renewing.

-----Original Message-----
From: Eric Werme USG [mailto:[email-masked]]
Sent: Monday, March 19, 2001 10:32 AM
To: Matthew J. Zito
Cc: [email-masked]
Subject: Re: NFS MIB ideas 

   At 10:02 PM -0800 3/15/01, Brent Callaghan wrote:
   >Actually, there's no easy way for a NFS server to establish whether a
   >client
   >has a filesystem mounted. NFS version 4 keeps track of which clients
   >have file open, or which locks are held - but not whether the client
   >has a filesystem "mounted".
   >

   Mmmmm...good point.  What if the mounting of a directory was treated 
   as a directory-level lock?  When the client mounts the directory, it 
   could place a lock on the directory that simply indicates that it has 
   it mounted.  An umount request could remove the lock.  Looking at the 
   RFC, it looks as though the LOCK definition only allows for file 
   locking.  If it was modified to permit a directory entry also, the 
   server could have information about which clients consider which 
   directories mounted.

I'm loathe to require a lock be held indefinitely.  File locking is
generally used for brief periods to atomically update a file or to
guarantee a file remains unchanged whileit is being accessed.

I assume you're talking about a read lock.  Therefore, if some other
application wants to write lock a directory, say for updating several files
that make up a database, to prevent other database clients from seeing
an inconsistant directory, that won't work on NFS.

In later mail you note:

  Mmm - I don't mean lock, as in "lock for writing", I mean a LOCK_RT 
  on the directory itself - that would indicate to the server that the 
  directory should be considered "mounted". 

What's LOCK_RT?  I don't see it in rfc3010 or in Tru64 kernel sources.
Ditto LOCK_RD, if that's what you meant.

	-Ric Werme

---

From: Eric Werme USG <[email-masked]>
Date: Mon, 19 Mar 2001 11:35:14 -0500

which would include closing idle TCP connections.  I suppose you could
close the connection after each lease renewal if other activity hasn't
happened, but that's getting into silliness.

	-Ric

---

From: "Matthew J. Zito" <[email-masked]>
Date: Mon, 19 Mar 2001 12:01:03 -0500

>have this directory lock whose lease they kept renewing.

Sorry, I meant READ_LT - but on reflection, I agree that it doesn't 
make sense to "lock" something when its not really a lock.  The idea 
is inherently what is stated above - some sort of open or lock or 
access notification that will tell the server what is mounted.

I don't have a particular solution for the problem wrt. expired 
leases and inactive clients.  From a server-side implementation 
standpoint, perhaps the server could contain a list of client leases 
- when it receives an renew or one expires, it just removes an entry 
or updates a counter.  That information is only for the convenience 
of a systems administrator - no server-side determinations need to be 
made on the basis of that information.

Thanks,
Matt

-- 
Matthew J. Zito
Systems Engineer
Register.com, Inc., 11th Floor, 575 8th Avenue, New York, NY 10018
Ph: 212-798-9205
PGP Key Fingerprint: 4E AC E1 0B BE DD 7D BC  D2 06 B2 B0 BF 55 68 99

---

From: "Matthew J. Zito" <[email-masked]>
Date: Mon, 19 Mar 2001 12:14:25 -0500

>happened, but that's getting into silliness.

Well, one solution to that could be to make the renewal period very 
long - long enough that the tcp connection would idle out on its own.

Actually, what if the server kept a per-client list of filesystems 
mounted, and client accesses update the per-client counter 
expiration?  I could see how making it so that any nfs operation 
updates the counter would increase the load on the server, so what if 
an open, or some other common nfs operation on the server updated the 
client's timeout value?

If a client is completely idle, but is still up, having a filesystem 
renewal shouldn't add very much load to the server, since it can just 
update the timeout, and then drop the client back into obscurity.

Thanks,
Matt