On Thu, Mar 08, 2012 at 09:02:43PM +0000, Myklebust, Trond wrote:
> 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.
You're right, I wasn't thinking about the 4.1 case: so in the 4.1 case,
the server does know which client the setattr is coming from, and has
the option not to recall. And in 4.1 you have the option of asking for
no delegation.
So your question was whether to preemptively return in the 4.0 case?
--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
