From: Noveck, Dave (dave.noveck@netapp.com)
Date: 11/03/99-11:12:29 AM Z
Message-ID: <4080CE03B682D311B589009027C2286638D330@tahoe.corp.netapp.com>
From: "Noveck, Dave" <dave.noveck@netapp.com>
Subject: RE: Some issues with stateid's
Date: Wed, 3 Nov 1999 09:12:29 -0800
> On Wednesday October 27, dave.noveck@netapp.com wrote:
> >
> > All of the stateid fields are OK but one of the locks
> ^^^
> > designated by the stateid has been revoked. ("Yes,
> > that is our agreement, but I have decided it no longer
> > applies. So sue me").
>
> I think the above "one" should be "all".
> Unless there is a reliable way for the client to determine which lock
> (or DENYal, or delegation) was revoked, there seems little point in
> revoking one lock without revoking them all, and I can't see a client
> doing anything useful with the remaining locks when one is gone.
Given the stateid architecture, if you've lost one lock you've
effectively lost them all. Any time you use the stateid you'll
get NFS4ERR_EXPIRED, so you can't use the locks to do IO, you can't
revalidate locks that weren't taken away since using the stateid
will give you an error, you can't release the locks in question.
The question is how the spec should deal with this issue.
For pure revocation, I think we should just define revocation
as happening to the all the locks for a given file-lockowner
pair at the same time, so you would change "one of the
locks" to the "the locks" or "all of the locks".
The other case is lease expiration. When a lease expires,
the server may let you keep the lock subject to revalidation,
if nobody else wants a conflicting lock. I have been
treating losing the lock after expiration, as a kind of
revocation. In that case, you might lose one of your
locks due to a conflict but, but have others still
available. I agree this is of no value so maybe the
spec should say that once you lose one of your locks
due to expiration, the whole set of locks for that
file is revoked. I think we would need to slightly
change some definitions and do some rewording.
The most interesting case is if the leases for some of
your locks have expired but others have not. Suppose
you have a lease interval of 2 minutes and do a lock
at 11:00, another at 11:01, and if there is no IO,
the lease for the lock will expire at 11:02, while the
lease for the second will expire at 11:03 and is subject
to indefintie renewal as long as anyone on the client
does IO. You could thus have a situation in which
the first lock was given to someone else, at say 11:02:30,
while the second lock still had a valid lease. I think
the spec has to make clear that the second lock gets
revoked (even before lease expiration) when the first
one is given to someone else. Right now the idea is
that revocation within the expiration period is a special
action, due to administrator command, for example,
so the spec would have to be changed to allow this
to happen as a result of lease expiraion on a another
lock for the same file-lockowner pair.
Another issue is once you get in this state, how does the
server ever get rid of the state it is holding for the
stateid. Normally, you can get rid of the state
by returning all of your locks (CLOSE+UNLOCK) but since
you can't do that with a bad stateid, it's unclear how
this stuff could ever be deallocated on the server,
given the protocol as it stands. This is tied in with
your EXIT/CLOSE suggestions which I'll try to respond to
soon.
This archive was generated by hypermail 2.1.2 : 03/04/05-01:47:48 AM Z CST