Subject: RE: [nfsv4] Clarification on READ with an all bits 1 stateid

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 2 May 2003 11:57:02 -0700

> >From the spec,
> 
> "For a READ with a stateid value of all bits 0, the server MAY allow
> the READ to be serviced subject to mandatory file locks or the
> current share deny modes for the file.  For a READ with a stateid
> value of all bits 1, the server MAY allow READ operations to bypass
> locking checks at the server."
>
> In the all bits 1 case, does "bypass locking checks" mean oshare 
> reservation checks and byte range lock checks if the server is a mandatory 
> locking platform?

That's the way I read it, given that the previous sentence mentions
both mandatory file locks and share deny modes.  If the intention 
was not to include both, I think a term that clearly referred to 
one or the other would be used.  "Locking checks" is something that
covers both and I don't think that's an accident.  What isn't
clear is whether a server may allow such a request to bypass some 
locking checks and not others.  That would allow a server to 
bypass mandatory locking and not bypass share reservations.  So
while I think the server is definitely given permission to bypass
the share checks in this case, I'm not so clear whether he is
given permission to apply them while bypassing the mandatory byte 
range locks.

> I assume for a POSIX advisory locking platform, the byte range lock checks 
> don't apply.

Yes.

> Is anyone thinking of allowing the bypass of "locking checks" on all bits 
> 1 in their server implementation. 

No current plans.  No plans to have plans to do this.  But I'm not 
going to say "never".  It depends on what customers want.  

> If "locking checks" also means oshare 
> checks, doesn't it sort of defeat the feature of oshare reservations?

Yes, but this is only read.  I'm assuming that the intention of
this is for somethng like backup.  Today, the issue doesn't arise 
because backup is done with some sort of local access and the v4
ruls don't apply.  If someone wants to do a backup and use v4 to 
access the files, then it might be reasonable for him to say that
he want to be able to backup a file even though someone has it 
opened denying read.  If clients implement a way for him to request
all-ones stateid to do this read, and customers need that functionality
then I could see creating an option to allow the locking checks to
be bypassed  in this case.
 
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: David Robinson <[email-masked]>
Date: Fri, 02 May 2003 14:44:39 -0500

> given permission to apply them while bypassing the mandatory byte 

The original motiviation for special stateids was the realization
that there are an interesting number of OSes and applications that
simply will not like the introduction of locking semantics.  Some
cases there simply may not be a way to accomplish an OPEN or
a way to handle failures. A client that knows that violating
the lock will not impact its view of consistency. Think of diskless
booting, booting a printer, bypassing a lock on /etc/passwd.

However, to blindly allow a client to do this could cause
some servers to cause inconsistencies or they may simply
not have a mechanism not to allow locking to by bypassed.  Thus
the decision to allow the special stateid semantics is that of
the server and the client must be able to handle an error.

It was always intended to cover any case where a stateid is used.

	-David

---

From: Benny Halevy <[email-masked]>
Date: Tue, 13 May 2003 21:23:52 -0400

> be bypassed  in this case.

Wouldn't it make more sense to use the ACL for such a feature: i.e. 
allow someone (e.g. backup admin account) to overide locks for read access?

I know this is not in NFSv4 but could be much more elegant than the all 
bits 1 solution.

--
Benny Halevy
[email-masked]