lkml.org 
[lkml]   [2012]   [Mar]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 2/2] NFSv4: Return the delegation if the server returns NFS4ERR_OPENMODE
    On Thu, Mar 08, 2012 at 08:50:14PM +0000, Myklebust, Trond 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@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.

    The server's only legal option is to recall it, so it seems odd not to
    pre-emptively return--but as you say there's nothing to prevent the
    server from then handing one right back, possibly before you get a
    chance to send the setattr.

    (And the linux server might well do that--maybe it should have some
    heuristic not to hand out a delegation that was just returned--not so
    much for this case as just because a return is a sign that the
    delegation isn't useful to that client.)

    --b.


    \
     
     \ /
      Last update: 2012-03-08 21:59    [W:0.021 / U:5.084 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site