Re: Alternative locking proposal

New Message Reply About this list Date view Thread view Subject view Author view Attachment view

From: Carl Beame (beame@mail1.tinet.ie)
Date: 08/17/98-09:08:15 AM Z 

From: Carl Beame <beame@mail1.tinet.ie>
Subject: Re: Alternative locking proposal
Message-Id: <1998Aug17.153714+0100@games>
Date: 17 Aug 1998 15:08:15 +0100

On Mon Aug 17 05:49:12 1998, David Robinson wrote:

> 
> Alternative to locking proposal in draft-shepler-nfsv4-02
> ---------------------------------------------------------

I agree very strongly with your suggestions for locking with one
"reservation :-)".

> Share reservations
> ==================
> 
> A share reservation is a mechanism to control access to a file.  It is
> a separate and independent mechanism from record locking.  When a
> client that supports shares opens a file, it issues a SHARE request to
> the server specifying the type of access required (READ, WRITE, or
> BOTH) and the type of access to deny others (deny NONE, READ, WRITE,
> or
> BOTH).  If the SHARE fails the client will fail the open request.
> Because there is not an explicit open procedure in NFS, clients who
> need to maintain consistency based on shares must use the SHARE
> procedure.  However, unlike mandatory locking, clients who do not
> enforce SHARE semantics may gain access to files.
> 

Most Unix people believe that SHARING can be implemented separately
from the regular NFS file system semantics. This is not the case!!! To
illustrate the point, let us assume the semantics of NFS V3 and try to
construct the NFS calls for a simple Created-Shared call while taking
into account all the other possible functions another PC on the
network could do.

The first guess would be:

1) File = Create(name)
2) If Failure Return Create Error
3) Share1 = Share(File)
4) If Failure Return Share Error
5) Return Success

Now this can cause problems because the "name" could already be
open by another PC and the Create would overwrite the file with out
checking if the file is shared.

Lets try:

1) File = Lookup(name)
2) if File Not Found goto 8
3) Share1 = Share(File)
4) If Failure Return Share Error
5) File = Create(name)
6) UnShare(Share1)
7) If Create Failed Return Error
8) Share(File)
9) If Failure Return Share Error
10) Return Success

This handles the problem of the file already being open, but it does
not handle the case of the file not existing and both creates being
executed. Both creates might succeed and both Shares will succeed but
later the PC which executed the first create will get a STALE file
handle on some read or write.

This is far more comprehensive:

1) File = CreateIfNotExist(name);
2) If Failure not due to existing file return Error
3) If Success goto 15
4) File1 = Lookup(name)
5) If File not found goto 1
6) Share1 = Share(File1)
7) If Failure Return Share Error
8) File = Create(name)
9) if Failure goto 13
10) Share2 = Share(File)
11) UnShare(Share1)
12) Return Success
13) UnShare(Share1)
14) Return Create Error
15) Share2 = Share(File)
16) If Failure return Share Error
16) return Success

This looks like it might work ... except if another PC executes a
Lookup(name)/Share(file)/Delete(file)/Unshare(file) between step 1,2,3
and 15.

> 
> Old DOS applications specify shares in compatibility mode.  Microsoft
> has indicated in the Win32 specification that it will be deprecated in
> the future and recommends that deny NONE be used.  This specification
> does not support compatibility mode.
> 
I think now is the time that Unix took a step forward and looked at the
introduction of Sharing into the file system semantics. If we
integrated Sharing into the file system part of NFS and defined a Unix
mode of sharing which disallowed write access to a file opened with
true sharing that disallowed write access everybody would be happy. Old
applications like CAT, TAIL would still work and eventually Unix
programmers would have a richer environment to program in.


If we can't agree an integrated SHARING solution, we then need to add
the following to any SHARING specification:

1) If the file specified in the SHARE request does not exist then an
error of File_Not_Found is returned. (This does not apply to the
UNSHARE request).

2) For every PC based function, Open/Rename/Delete/Create ... pseudo
code is supplied which MUST be followed when implementing the
specific functions over NFS V4.

- Carl

New Message Reply About this list Date view Thread view Subject view Author view Attachment view

This archive was generated by hypermail 2.1.2 : 03/04/05-01:46:09 AM Z CST