Subject: Re: special stateids (was "LOOKUP vs OPEN in NFSV4")

From: David Robinson <[email-masked]>
Date: Fri, 24 Aug 2001 11:36:59 -0500 (CDT)

> It's certainly true that being able to map I/Os to lock owners is
> necessary for mandatory locking.  But IMHO, in the Unix world (at
> least the part of it I originally come from), "mandatory locking"
> connotes "locking is enforced even for programs that don't play nice",
> and "advisory locking" connotes "locking is only enforced for programs
> that play nice" (and "play nice" means getting locks that cover your
> I/Os).  And I believe that the comments in the RFC about the all-zero
> stateid and mandatory locking were written in the context of that way
> of thinking.

Be careful here, even with advisory locking stateids are essential.
In fact they were introduced before mandatory locking was seriously
considered. If you look at any type of locking, the lock or unlock
functions are a synchronization point with the I/O operations
that are necessary to meet the consistency requirements inherent
to any form of locking. The change of stateid allows the server to
determine if the I/O is pre or post the synchronization point
so it can accept or reject it. So while an all-zero stateid allows
a client to play fast and loose, it is still not strong enough to
implement Unix advisory locking when the underlying RPC transport
is not truely reliable (i.e. even TCP has connection resets).

	-David