Subject: Re: [nfsv4] Semantics of mandatory byte-range locking

From: [email-masked]
Date: Thu, 14 Sep 2006 12:27:45 -0400 (EDT)

> OK, then what is POSIX mandatory locking?

Got me. On pg. 257 of my old dusty POSIX.1, it says "Mandatory locks were
omitted for serveral reasons:" followed by blah, blah, blah.
(Was there a re-write of POSIX.1 that added this?)

> So suppose client A opens the file which has the mandatory lock
> "bit" set in the mode. Mandatory locking is enabled, and
> the server communicates to the client. Then the mandatory lock
> bit is cleared. Now client B goes to open the file. Since
--> Shouldn't allow clearing while it's open.
> A still has it open, mandatory locking has to stay on. Now A closes,
> and mandatory locking is still on. Now C opens the file, and
> mandatory locking is still on. So for a popular file, once
> mandatory locking is on, it stays on.

No problem, from my point of view. I think file systems should implement
either advisory locking or mandatory locking and shouldn't flip back and
forth. (I don't really care if the granularity is "per-file" or
"per-file-system".)

> Now the server reboots. After reclaim, since the mandatory 
> lock bit is not on, it doesn't know it is supposed to enforce locking
> on I/Os. 

As above, the state shouldn't be allowed to be changed while a file is
open and has to be on stable storage, per-file or per-file-system.

> I understand your issue, but I don't see a simple solution.
> I think the presence of the mandatory lock bit (combined
> with the NFS4ERR_LOCKED error) is sufficient
> indication  for those who really need mandatory locking.
> A return flag from OPEN of _MLOCKED doesn't add much value,
> so it was dropped.

My simple (cheezey) solution is a client-side mount flag that forces all
I/O to bypass the buffer cache, combined with a note in the man page to
use this flag if the server might be implementing mandatory locking.
(No-one will use the flag, since it is a major performance hit, but I've
 covered my behind:-)

rick

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Mike Eisler <[email-masked]>
Date: Thu, 14 Sep 2006 10:01:26 -0700 (PDT)

> forth. (I don't really care if the granularity is "per-file" or

If they don't flip back and forth, then this means that the
attribute is specified on the file the
file system or volume is created, and is never changed.
That's raising the barrier to entry for servers. You might
be willing to do that, but most others won't (not without
proven customer demand).

Regardless, flipping the attriute on a SVID-compliant
server is a choice of the file owner. The problems flipping causes
are completely avoidable.

But let's say we have explicit attributes that
indicate whether the file will be using advisory or
mandatory locking and whether the semantic can flip (i.e.
the advisory/mandatory attribute is immutable). Now, what does a
Windows server return (there is no attribute to set or clear)?
To comply with the specification, it has to say the 
mandatory lock semantic is immutable. That's
going to suck. So again, the full solution includes a notification
that tells the client that on a file that supports mandatory
locking, some app has actually issued an byte range lock.
And similarly a notification that tells the client when there are
no more byte range locks. As with the pNFS consistency issues
we should be asking whether we are trying to add stronger
consistency semantics to NFS than what has previously existed.

The status quo solves this in a reasonable enough fashion for
UNIX clients and servers. It allows UNIX and Windows clients to
detect whenever there is an existing mandatory lock on a conflicting
range on a Windows server. It protects applications that want
to use mandatory locking from another app (that doesn't
want to use mandatory locking) that wants to write into a locked
range.  While it does allow clients to read data out of cache that
might have already been written, I don't see the
close-to-open consistency violation. I don't believe mandatory
lock ever had the requirement of preventing a non-cooperating
app from screwing itself or the cooperating app.