Subject: RE: NFS MIB ideas

From: "Noveck, Dave" <[email-masked]>
Date: Sat, 17 Mar 2001 12:44:44 -0800

This confusion derives from the fact that in V4 all opens,
whether they lock anything or not, are called "locks" along
with byte-range locks and delegations.  I think we would be 
better off if we had a word for this general construct other
"lock".

Anybody have any (serious) suggestions?

-----Original Message-----
From: Matthew J. Zito [mailto:[email-masked]]
Sent: Friday, March 16, 2001 10:44 PM
To: Brent; [email-masked]
Subject: Re: NFS MIB ideas

At 5:33 PM -0800 3/16/01, Brent wrote:
>"Matthew J. Zito" wrote:
>>  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.
>
>You wouldn't want to lock a directory - just flag it in some
>way to indicate that it is "in use".  What do you do when the
>client reboots and forgets which servers it had mounted when
>it died?  You could put a lease on the flag, but that would
>require a client to periodically "ping" the server to keep
>the lease alive - even when the mount wasn't in use. That
>would be a bad idea.
>
>A better idea might be to have the server keep track of
>which clients have used the filesystem "recently" and
>give the sysadmin access to that information.  No protocol
>changes are required for that.
>

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".  The lock would be simply 
for informational purposes, and could be handled in the same way as 
any other lock.  If a better way to do that would be to implement an 
"in use" flag, that would be fine - I was just thinking that doing 
this within the existing structure of the protocol would be useful.

When a client reboots, the client has to have a knowledge of what 
filesystems to mount anyway - so it doesn't matter that it previously 
had it mounted - it'll just re-lock the directory when its mounted.

Server-side access tracking would be equally useful, but would serve 
a different purpose.  Any reasonable list of recently-accessed files 
on a per-client basis could quickly hide the filesystem information. 
The point of keeping track of mounts is to allow the server 
administrator to monitor who is mounting what directories and when, 
something that is very useful, and not available.

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: Neil Brown <[email-masked]>
Date: Tue, 20 Mar 2001 14:02:33 +1100 (EST)

> Anybody have any (serious) suggestions?

I thinks words and names are very important, and it would be good to
have a name for such an important concept.
The "obvious" name is an "open", but that is a verb, not a noun, which
will just lead to confuision.
I recommend
    reservation
and I do so without any reservations :-)

This word is already using in the RFC in the phrase "share
reservation" which is something that may happen at OPEN time.

NeilBrown

---

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

>reservation" which is something that may happen at OPEN time.

Well,  I like the name reservation - it fits the concept of accessing 
a resource without necessarily _doing_ anything with it.  But I'm a 
little unclear about what exactly would be changed with this - where 
would this be used and how?

Thanks,
Matt