Subject: [nfsv4] Forward of misdirected thread on NFSv4 mandatory locking...

From: Spencer Shepler <[email-masked]>
Date: Thu, 5 Jun 2003 16:02:07 -0500

I am forwarding a thread that went to the old alias.

Obviously, I will be fully disabling the old alias soon.

-- 
Spencer

Subject: Benefits of Mandatory Locking
From: Stevan Steve Allen <[email-masked]>
To: [email-masked]
Date: Tue, 3 Jun 2003 23:46:00 -0700

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

Subject: Re: Benefits of Mandatory Locking
From: David Robinson <[email-masked]>
To: Stevan Steve Allen <[email-masked]>
Cc: [email-masked]
Date: Wed, 04 Jun 2003 08:37:55 -0600

Stevan Steve Allen wrote:
> 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

This demonstrates the risk of using a zero stateid and why
it should not be encouraged when data consistency is needed.
This problem exists today with NFSv3/NLM, multiple clients
following proper locking protocol can get their data wiped
out by a non-participating client. Even if Appl1 doesn't
use a zero stateid, but instead only locks the subrange
in each request, corruption occurs, in both cases this
is a programming error.

> 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?

If you have applications that are using locking, it is very
reasonable to use ACLs to disallow users that may want
to run applications that don't understand the locking
convention.

I think there may be a difference in the use of the term
"mandatory". (It does have different semantics between
SYSVR3 Unix and Windows). In NFSv4, mandatory means that
an I/O operation using a normal stateid will get an error
back when a conflicting lock exists.  If no locks exists,
no I/O operation will fail with a locking error. Mandatory
doesn't mean that you have to use locking, it only means that
when you do lock a range, for the duration of that lock
you will not get a conflicting I/O operation.  But it is
still the requirement of applications to set locks as
they see fit.

There are two motivations of the design, the first was the
incorporation of a stateid in I/O operations so there
could be a correlation between a client holding a lock
and the I/O.  Before, if a request got reordered or delayed
due to a networking problem, a client diligently following
locking could clobber its own data. But it was still presumed
that the client would still be responsible for determing
what I/O operations will be issued with a lock and those
without.  The stateid just allows the server to catch cases
where I/O issued based on the clients understanding
of the "current" state, are still valid. The second
decision was to decide if we should cause I/O
operations to fail when they conflicted with a lock.
In the core Unix base this was unneeded, and actually
unwanted by a lot of folks.  But in the Windows
world they have the semantic that the I/O must not
complete it a conflicting lock is held.  So we added
mandantory locks to cover all bases.

But what we never did was to setup a mode where the
server can tell a client that it could only do
I/O operations when a lock was held.  Frankly I
never heard anyone even suggest such a thing, although
I now can see how it could be useful. Minor version
anyone?

	-David

Subject: RE: Benefits of Mandatory Locking
From: "Yoder, Alan" <[email-masked]>
To: "Stevan Steve Allen" <[email-masked]>, <[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
> 
> 

Subject: RE: Benefits of Mandatory Locking
From: Stevan Steve Allen <[email-masked]>
To: [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

> -----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
>
>

Subject: RE: Benefits of Mandatory Locking
From: "Yoder, Alan" <[email-masked]>
To: "Yoder, Alan" <[email-masked]>, "Stevan Steve Allen" <[email-masked]>, <[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
> > 
> > 
> 

Subject: Re: Benefits of Mandatory Locking
From: Stevan Steve Allen <[email-masked]>
To: [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