Subject: RE: Benefits of Mandatory Locking

From: "Yoder, Alan" <[email-masked]>
Date: Wed, 4 Jun 2003 11:36:33 -0700

because it's needed to model the locking semantics
of CIFS and other filesystems like it.  However,
after some years of messing around in multiprotocol
environments, I've come to the conclusion that those
dudes who settled on advisory locking in NFS v2 and v3
were pretty darn smart.  There are few things more
annoying than a client that obtains a mandatory lock
and then goes off into the weeds.

   As a noncombatant on this list, my opinion doesn't
count for much, but personally, I'd view a comprehensive 
solution to that problem a lot more favorably than 
"really mandatory locking".  

   Besides, wouldn't a server that implemented really 
mandatory locking break just about every utility program 
in the known world?  Do du, cp, mv, dd, more, dos copy and 
all their thousand brethren all obtain mandatory locks before writing/reading?  Wouldn't the client and server have to 
negotiate the behavior (and hide it from programs) to get 
around this problem?

Alan

===============================================================
Alan G. Yoder                                    [email-masked]
Technical Staff                           
Network Appliance, Inc.                            408-822-6919
=============================================================== 

> -----Original Message-----
> From: Stevan Steve Allen [mailto:[email-masked]]
> Sent: Tuesday, June 03, 2003 11:46 PM
> To: [email-masked]
> Subject: Benefits of Mandatory Locking
> 
> 
> 
> 
> 
> Given the following mandatory locking scenario using magic 
> stateid's, I'm
> having difficulty listing any claims or benefits the mandatory locking
> model provides which the advisory model does not.
> 
> 1. Appl 1 issues a large write
> 2. Large range is broken into two RPCs
> 3. 1st half of write is sent to the server with a zero stateid
> 4. No lock conflicts, partial write is successful and completes
> 
> 5. Appl 2 successfully locks the entire range of Appl 1's write
> 6. Appl 2 successfully writes entire range overlaying Appl 1 
> partial write
> 7. Appl 2 releases associated lock
> 
> 8. 2nd half of Appl 1 write is sent to the server with zero stateid
> 9. No lock conflicts, partial write overlays Appl 2 change
> 
> If the above scenario describes writing an image file, the resulting
> picture can be described as a mans head on a ducks body.
> 
> To ask the question in another way,  could an advisory 
> locking server using
> ACLs to limit access to trusted applications provide the same 
> benefits as
> an mandatory locking server?  If not, what is missing?
> 
> 
> On a different topic....  Someone once said unless a lock conflict is
> detected and nfs4err_locked is returned, the NFS client and client
> application will not be aware that a mandatory or advisory locking
> environment is in effect.  e.g. the application can perform all it's
> operations and end successfully without ever knowing.  Given 
> this, I assume
> any application written to handle the mandatory locking error 
> will also run
> unknowingly and unaffected in an advisory locking environment.  e.g.
> mandatory applications have no problems with advisory servers.
> 
> 
> Thanks,
> Stevan C. Allen
> 
>

---

From: Stevan Steve Allen <[email-masked]>
Date: Thu, 5 Jun 2003 11:03:24 -0700

Alan Yoder wrote:
|   As David said, mandatory locking was implemented
|because it's needed to model the locking semantics
|of CIFS and other filesystems like it.  However,
|after some years of messing around in multiprotocol
|environments, I've come to the conclusion that those
|dudes who settled on advisory locking in NFS v2 and v3
|were pretty darn smart.  There are few things more
|annoying than a client that obtains a mandatory lock
|and then goes off into the weeds.
|
|   As a noncombatant on this list, my opinion doesn't
|count for much, but personally, I'd view a comprehensive
|solution to that problem a lot more favorably than
|"really mandatory locking".
|
|   Besides, wouldn't a server that implemented really
|mandatory locking break just about every utility program
|in the known world?  Do du, cp, mv, dd, more, dos copy and
|all their thousand brethren all obtain mandatory locks
|before writing/reading?  Wouldn't the client and server have
|to negotiate the behavior (and hide it from programs) to get
|around this problem?

I agree the usage of more restrictive mandatory implementations is rare
until you start playing with enterprise mission critical data environment.
A scenario may likely describe a solution where access is limited to a few
(probably internal) client applications & platforms which follow the rules.
Access to all the worlds platforms in not needed when only a few
applications like finance are expected to participate.  Historically, it is
likely they will migrate a couple applications to another platform in order
to satisfy a needed solution such as the mission critical requirements of
their data.

I support the openness of NFS but I struggle with statements which hint of
NFS locking semantics taking precedence over platform semantics and
customer solutions.  For any customer needed solution which NFS can not
address, the customer will peruse alternative products (CIFS smiles).

- Steve