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

Dave.Noveck@netapp.com

Subject: RE: [nfsv4] Clarification on READ with an all bits 1 stateid
Message-ID: <C8CF60CFC4D8A74E9945E32CF096548A6D33BD@silver.nane.netapp.com>
From: "Noveck, Dave" <Dave.Noveck@netapp.com>
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
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4