[pnfs] [PATCH] nfsd: use list_del_init in unhash_stateowner
J. Bruce Fields
bfields at fieldses.org
Sun Jan 27 22:50:20 EST 2008
On Sun, Jan 27, 2008 at 10:15:06AM +0200, Benny Halevy wrote:
> On Jan. 26, 2008, 20:10 +0200, "J. Bruce Fields" <bfields at fieldses.org> wrote:
> > So I guess what happened was the client either expired (if the close was
> > blocked for a lease period without the client renewing?) or the close
> > got resent?
>
> I think that the client expired, though I don't have definite proof for that.
>
> >
> > The latter might have gotten caught if we had the replay cache turned
> > on. But this sort of thing is supposed to be caught even without a
> > replay.
> >
> > I'd hope a close would normally be something the filesystem can service
> > instantly--why does it need to wait on layout returns?
>
> The Panasas pnfs server does not allow the client to hold layouts beyond
> close as it needs to turn around and return this state internally.
>
> >
> > But if not then maybe we need something like the RC_INPROG that the rpc
> > cache has, to indicate that an operation is in progress on a given
> > stateid?
>
> Hmm, that might work. From the nfsv4.1 protocol standpoint this could even
> translate to a NFS4ERR_DELAY error (or a new error code, e.g. NFS4ERR_LAYOUT_HELD,
> similar to NFS4ERR_LOCKS_HELD. That said, I admit I'm not too fond of "inprog" errors...
That RC_INPROG state in the rpc cache isn't an error--it's just a flag
set on an rpc cache entry which indicates that the server is already
handling that request, used in determining how to respond to replays.
In the 4.1 case I assume the sessions layer deals with that. If we're
going to drop the state lock here in the 4.0 code as well, then I guess
we'd need to have a way to mark a stateid as having an operation in
progress on it.
> The pnfs server can also check for the existence of layouts on close when
> the exported file system indicated "return_on_close" when it dispatched the
> layout and start the layout recall process before taking the state lock.
> This should gracefully prevent this case rather than handling it retroactively.
--b.
More information about the pNFS
mailing list