Subject: additional issue resolved

From: Spencer Shepler <[email-masked]>
Date: Wed, 7 Aug 2002 12:26:17 -0500

One issue I failed to mention as resolved is 218 (which was new from
yesterday).  This deal with mandatory file locking discussion in the
specification.

Also note that there are new issues posted (216-221).

http://www.nfsv4.org/rfc3010updates/issues.html

-- 
Spencer

---

From: [email-masked]
Date: Wed, 07 Aug 2002 15:42:21 -0700

Section 8.3 of the latest I-D says

     (since blocking atomic upgrade is impossible to implement,
     WRITEW_LT is never appropriate for an upgrade, and the server
     should return NFS4ERR_INVAL).

This doesn't make sense to me.  WRITEW_LT provides a hint that the
client will block the request at its end and periodically retry, and
the server should maintain a list of pending requests in an attempt to
provide fairness.  Why can't the same thing happen for an upgrade?

I'm okay with the spec going out as is (on this issue), but POSIX
*does* allow for blocking upgrades.  The request just blocks until all
the conflicting locks go away.  So it seems that POSIX-based clients
will want to support blocking atomic upgrade, even if the protocol
says that the client can't use WRITEW_LT.

mike

---

From: Mike Eisler <[email-masked]>
Date: Wed, 07 Aug 2002 12:28:20 -0700

> says that the client can't use WRITEW_LT.

Despite what POSIX may say, blocking *atomic* upgrade is impossible to implement.

Thread A holds a read lock.
Thread B holds a read lock

Threads A and B want to upgrade to a write lock. They do blocking
upgrades. If POSIX says the threads block until the conflicting locks
go away, then POSIX is mandating a deadlock.

Is it the case that POSIX says threads A and B get EDEADLCK? I
suppose it is possible ... do POSIX implementations of advisory
locking check for this deadlock?

In any case, since NFS4ERR_DEADLCK has been added to the specification,
I'm OK with altering the specification to allow servers to attempt
this.

	-mre

---

From: [email-masked]
Date: Thu, 08 Aug 2002 12:17:54 -0700

>>>>> "mre" == Mike Eisler <[email-masked]> writes:

    mre> Thread A holds a read lock.  Thread B holds a read lock

    mre> Threads A and B want to upgrade to a write lock. They do
    mre> blocking upgrades. 
[...]
    mre> Is it the case that POSIX says threads A and B get EDEADLCK?

I believe that POSIX makes deadlock detection optional.

    mre> I suppose it is possible ... do POSIX implementations of
    mre> advisory locking check for this deadlock?

Solaris does, both locally and over NFS v3.  The first process
requesting the upgrade blocks.  The second process requesting the
upgrade gets EDEADLK.

    mre> In any case, since NFS4ERR_DEADLCK has been added to the
    mre> specification, I'm OK with altering the specification to
    mre> allow servers to attempt this.

Yeah, the current (02-03) I-D looks good.

cheers,
mike