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

From: [email-masked]
Date: Wed, 13 Sep 2006 10:56:21 -0400 (EDT)

Since you've brought up mandatory locking, there's something that I've
never figured out about it.

How is a client supposed to know if a server is applying mandatory locking
on a file or not? (RFC3010 had the OPEN4_RESULT_MLOCK rflag for Open, but that
was dropped for RFC3530.)

Suppose a file has mode 644 and a client doesn't have a user credential for
the owner of that file. The client can Open the file for reading, but I can't
see how it can know if the server is doing mandatory locking on it. And why
does the client care?

Well, my interpretation of RFC3530 Sec. 9.3.2 is that, if the server is
doing mandatory locking on the file, then the client must get byte range
locks for all byte ranges being cached. If it doesn't do this, a read
could succeed on the locally cached data when a conflicting lock is held
for that byte range by another client.

Is this really a problem, or am I just confused, like usual? rick

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

---

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

> see how it can know if the server is doing mandatory locking on it.

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

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.

An NFSv4 client can see in the attributes 
  if ((mode & 02000) && !(mode & 00010))
and use that as the clue that it shouldn't cache
the file.

> locks for all byte ranges being cached. If it doesn't do this, a read

Right. A client could also learn that mandatory locking is going
on by attempting the I/O and getting NFS4ERR_LOCKED. But that
doesn't help if the conflicting byte range lock is acquired
after the file is locked.

> for that byte range by another client.

It's a problem for servers that don't use 02000 to convey
mandatory locking. For example, my understanding is
Windows always has mandatory locking enabled. Any byte range lock on a
file in Windows causes a conflicting
I/O to get a locking error. Since we don't have an "I'm a Windows
server" attribute then technically, a client should always
get a byte range lock before doing any I/O out of cache or never
read out of cache if there is no delegation or byte range lock.
Practically, that isn't going to work; clients that assume
the server does Windows byte range locking semantics and that
byte range locking will be used will suffer (even if we had
the "I'm a Windows server" attribute).

Anyone know what CIFS clients do? Do they read out of cache
when they don't have an op-lock?

> Is this really a problem, or am I just confused, like usual? rick

I suppose a more complete solution is for
the client to get a notification: the client is notified that
a file the client is caching is now under mandatory lock
semnatics. Might be a job for directory notifications (i.e.
DIR_NOTIFICATION_CHANGE_MAND_LOCK). A notification for
the converse is might be good too: tell the client that the file
no longer has mandatory lock semantics enforced. But that is
harder in the Windows server case. E.g.

  client 1 opens the file on a Windows sercer,
   does some I/O without locks.

  client 2 opens the files,and its app explicitly
   gets a byte range lock

  client 1 gets notified that mandatory locking is in force

  client 1 now gets a byte range lock

  client 3 opens the file and is told manatory locking is in force
    and so it prefixes I/Os with lock requests.

  client 2 closes the file.

  Should client 1 and client 3 be notified that mandatory
  locking is no longer in force? But what if a process on client 3
  starts to explicitly obtain  byte range locks? So we would
  apparently need to distinguish LOCK requests driven by the
  app versus those acquired by the client's NFS file system on
  behalf of the app for mandatory locking semantics.

Maybe there's a solution, but it looks involved. Perhaps
what we have today is good enough.