On Thu, 2012-03-08 at 15:57 -0500, J. Bruce Fields wrote:
> 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@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.
>
> 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.
Why would it need to recall it if this is the only client holding a
delegation? I agree that for the case of NFSv4 once we don't send the
stateid, the server has no way to know that this is the same client, but
the NFSv4.1 server doesn't have that limitation.
> (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.)
Umm... An NFSv4.1 client could simply request a delegation. As I said
earlier, we don't keep tabs on what other processes are doing.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@xxxxxxxxxx
www.netapp.com
��.n��������+%������w��{.n�����{���)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
