From: Boris Z. (boris@conley.com)
Date: 10/08/98-12:03:29 PM Z
Message-ID: <01BDF2A2.E6A293C0.boris@conley.com> From: "Boris Z." <boris@conley.com> Subject: RE: locking errors Date: Thu, 8 Oct 1998 10:03:29 -0700 David, If I understand correctly, lockid was designed mostly to support operations associated with a single lock. We need support two distinct cases: 1) validation of a single lock and 2) validation of all locks. A client should be able to issue a request (zero length READ or may be some other ) with last obtained lockid and gets beck NFS4_OK, if ALL its locks still valid, or NFS4ERR_EXPIRED, if ANY of its locks were discarded, as well as get information what lock were discarded. b. On Wednesday, October 07, 1998 5:53 PM, David Robinson [SMTP:David.Robinson@Eng.Sun.COM] wrote: > > It looks like David's proposal does not include any indicators (verifiers) > > that locks were not removed even when lease TMO expired. > > Does this mean that in case of disconnect for longer then a lease TMO > > a client must pessimistically abort an application? > > If yes, it's a problem that has to be fixed. > > It may not be clearly stated, but I/O operations contain a lockid > which the server uses to verify that the lock is still valid. If > it is not valid the server returns back either: > NFS4ERR_EXPIRED = 10011, /* lock lease expired */ > NFS4ERR_GRACE = 10013, /* in grace period */ > > See paragraphs 3 and 4 under Crash Recovery. > > The key is that any operation that depends on the lock for correctness > (read/write) must send their lockid along so that no operation can > succeed if the lock is revoked. > > But what is missing is the lockid for LOCK requests to upgrade or > downgrade existing locks that may have been revoked. Simple fix > is to an a lockid to the LOCK4req structure (zero == no previous lockid) > > -David
This archive was generated by hypermail 2.1.2 : 03/04/05-01:46:32 AM Z CST