Subject: RE: Benefits of Mandatory Locking

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

Grrr.  Let's see if the gremlins can get it wrong
the same way twice....

> -----Original Message-----
> From: Yoder, Alan 
> Sent: Wednesday, June 04, 2003 11:37 AM
> To: 'Stevan Steve Allen'; [email-masked]
> Subject: RE: Benefits of Mandatory Locking
> 
> 
>    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?
> 
> 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 13:00:58 -0700

Misdirected email, re-posting on forum.

David Robinson wrote:
|Stevan Steve Allen wrote:
|> To limit my initial topic..  Given a different mandatory environment
where
|> the server is a core Unix (not Windows), and data consistency is "not"
|> enforced, and non lockers using special stateid's are allowed as defined
in
|> the draft, I do not see a server claim or benefit being provided by
|> implementing the mandatory locking model  "with" special stateid's that
an
|> advisory locking model can not provide.  It seems the only servers which
|> benefit from mandatory locking is Windows & some Posix implementations
|> which require data integrity.
|>
|> I don't see any of the core Unix base platforms you mentioned will
benefit
|> from these two locking decisions and suspect they will not implement
|> mandatory locking based on these decisions.  If they do, I would still
|> setup advisory locking for performance without fear of loosing any
ability
|> or compatibility concerns.  Basically, if your going to allow magic
|> stateid's I don't see any benefits.
|
|Pretty much most Unix implementations have no use for mandatory
|locking and we will see how widely it is implemented. It has
|nasty implications when something leaves a mandatory write lock
|on a file such as /etc/passwd causing a massive denial of
|service.  Conversely, without mandatory locking an interesting
|number of Windows applications will be unsupportable, magic stateids
|were the hack to bridge the gap.

Are you describing a Windows server implementation to support Unix clients,
or Unix server implementations to support windows clients? Or both?  I
suspect the first one due to the recent discussion.

Regarding a server allowing magic stateid's on write
i.e. implementing lock contention rules outlined in the draft:

The following illustrates the dilemma of dedicating effort to mandatory
locking.

Lets pretend we both provide NFS server products for the same unix platform
whose kernel does not enforce data consistency.  If one product provided
mandatory locking where they enabled reorder detection by not allowing
magic stateid's, the product could claim a benefit over an advisory only
product.  But if a Unix NFS server product claims to support mandatory
locking, and magic stateid's, the product would not be able to claim any
benefits to persuade customers not to migrate to a competitive advisory
only product.

The issue is, I see no benefits of allowing magic write stateid's as
described in the draft on a unix server.  If a Unix server product allows
magic writes, they can not claim any solution benefits over competing NFS
server products which are advisory only.

Please prove me wrong.

-Steve