Re: [PATCH 2/2] NFSv4: Return the delegation if the server returns NFS4ERR_OPENMODE

["Myklebust, Trond" <Trond.Myklebust@netapp.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1960 bytes --]

On Thu, 2012-03-08 at 15:42 -0500, J. Bruce Fields wrote:
> On Thu, Mar 08, 2012 at 03:23:34PM -0500, Olga Kornievskaia wrote:
> > On Thu, Mar 8, 2012 at 1:15 PM, Myklebust, Trond
> > <Trond.Myklebust@netapp.com> wrote:
> > > On Thu, 2012-03-08 at 12:52 -0500, Olga Kornievskaia wrote:
> > >> wouldn't it be better for you to proactively return a read delegation
> > >> then unnecessarily erroring?
> > >
> > > If nobody else holds a delegation, then the NFS client is actually
> > > allowed to keep its read delegation while writing to the file. It does
> > > admittedly need to request an OPEN stateid for write in that case...
> > > (See section 10.4 of RFC3530bis draft 16)
> > 
> > If we both agree that there has to be a request for an open stateid for
> > a write, then instead of returning the read delegation if the client receives
> > err_openmode (when it send the request with read delegation stateid
> > as you said per 3560bis), can't the client resend the setattr with the open
> > stateid? The ordering of the stateid usage is a "should" and not a "must".
> > 
> > In rfc5661, it really doesn't make sense to ever send a setattr with
> > a read delegation stateid. According to 9.1.2, the server "MUST" return
> > err_open_mode" error in that case.
> > 
> > I gather you are in this case dealing with 4.0 delegations. But I wonder
> > if you'll do something else for 4.1 delegation then?
> 
> 3530bis has the same language ("...must verify that the access mode
> allows writing and return an NFS4ERR_OPENMODE error if it does not").

OK, so we shouldn't send the delegation stateid either for v4 or v4.1.
However should we pre-emptively return the delegation? I've been
assuming not.

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥