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

From: [email-masked]
Date: Thu, 14 Sep 2006 11:02:09 -0400 (EDT)

> It the mode is 0644, the server isn't applying mandatory
> locking, at least, not a UNIX server. The mode would have to
> be 02644 (the set gid bit combined with the absence of
> the group execute bit).

Although that behaviour is mentioned in the RFC, the wording doesn't seem
to make it required behaviour for mandatory locking. (I assume it is a
part of SVID because I don't think it's POSIX?)

> The problem with OPEN4_RESULT_MLOCK is that mandatory lcoking
> and be enable or disabled at will for a file, at least
> in UNIX, by virtue of the mode bits.

And, although that may be "UNIX" behaviour, I don't think it is acceptable
NFSv4 server behaviour.

The problem is that, if the server can flip between mandatory and advisory
locking at will, the client must check against the server (Getattr Op if
the mode bits are the standard way to tell) before every access to the
local cache, unless a byte range lock is already held for that byte range.
In other words, a client must do one of:
A) A Getattr against the server before every I/O is handled by the client
   side cache. (I could even argue this isn't sufficient, since the server
   could change from advisory locking -> mandatory locking between the
   Getattr reply being sent by the server to the client and the client
   allowing the I/O op to happen against the local cache.)
OR
B) Grab byte range locks for all byte ranges cached for all files, for all
   servers.

Either A) or B) seems to be an unacceptable performance hit and I suspect
current clients aren't doing either of them.

I think that there needs to be a "don't switch between advisory <-> mandatory
locking on a file while it is Open" restriction on the server.

Since no-one else seems concerned about this, am I missing something here? rick

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

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 14 Sep 2006 11:12:38 -0400

> local cache, unless a byte range lock is already held for that byte range.

There are currently 3 caching models that NFS supports:

 1) Close to open cache consistency.
 2) Byte range locked.
 3) Uncached (i.e. O_DIRECT) reads/writes

For which of the above 3 cases are you and Mike arguing that we have a
problem?

Cheers,
  Trond

---

From: Eric Werme USG <[email-masked]>
Date: Thu, 14 Sep 2006 11:35:19 -0400

I believe Posix says mandatory locking is not mandatory to implement.

   Since no-one else seems concerned about this, am I missing something here?

Mandatory locking?  Run away!  Run away!  At the very least, it behooves
people to not let NFS server threads block when accessing a locked file.
I forget how Tru64 does mandatory locking, I think it's at the VFS layer
that system calls use and the NFS server doesn't. Hence we can use NFS to
get around mandatory locking....

	-Ric Werme

---

From: Mike Eisler <[email-masked]>
Date: Thu, 14 Sep 2006 08:52:35 -0700 (PDT)

> part of SVID because I don't think it's POSIX?)

OK, then what is POSIX mandatory locking?

> locking on a file while it is Open" restriction on the server.

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
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.

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. 

These issues could be fixed (e.g. the server includes a mandatory
lock bit in the stateid, and on lock reclaim, LOCK takes
the original stateid so that the server knows what is expected).

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.

> Since no-one else seems concerned about this, am I missing something

That in the UNIX world at least, mandatory byte range
locking has a narrow use case. What we have there works, even with
the edge conditions you've noticed. The edge conditions are
avoidable: don't fiddle with the mandatory lock enable attribute
of a file.

---

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

> people to not let NFS server threads block when accessing a locked

Yes, the NFSv4 spec says the server should return NFS4ERR_LOCKED
when I/O is don for a file that the state owner either has no
lock for, or cannot immediately get a lock for.