On Thu, Mar 8, 2012 at 3:50 PM, Myklebust, Trond
<Trond.Myklebust@xxxxxxxxxx> wrote:
> 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@xxxxxxxxxx> 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.
It would be nice not to pre-emptively return delegations but for that
we need server implementors to get on board with the idea.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
