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

New Message Reply About this list Date view Thread view Subject view Author view Attachment view

From: David Robinson (David.Robinson@Sun.COM)
Date: 05/02/03-02:44:39 PM Z


Message-ID: <3EB2CAA7.4030105@Sun.COM>
From: David Robinson <David.Robinson@Sun.COM>
Subject: Re: [nfsv4] Clarification on READ with an all bits 1 stateid
Date: Fri, 02 May 2003 14:44:39 -0500

Noveck, Dave wrote:

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

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

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4


New Message Reply About this list Date view Thread view Subject view Author view Attachment view

This archive was generated by hypermail 2.1.2 : 03/04/05-02:12:20 AM Z CST