Subject: RE: [nfsv4] rfc3530 clarification

From: "Noveck, Dave" <[email-masked]>
Date: Sat, 21 Jun 2003 14:56:29 -0700

I still interpret it as FYI from the viewpoint of spec
compliance, but I can see that it might support a user's
claim that, if your server is UNIX, or you claim UNIX
suppport, you should do this.  

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Saturday, June 21, 2003 4:34 PM
To: [email-masked]
Subject: [nfsv4] rfc3530 clarification

The first time I read this I assumed that, since it said "in UNIX", that
it was simply FYI, but now that I see it says "must" in it, I'm not so
sure.

   Note that in UNIX, if a file has the MODE4_SGID bit set and no
   MODE4_XGRP bit set, then READ and WRITE must use mandatory file
   locking.

Does this mean that an NFS V4 server should/must obey this convention?

How widely adopted is this tradition?

Thanks in advance for any help, rick
ps: If required, it kind of supersedes my previous email, although an
    attribute that indicates that a file server uses mandatory locking
    for all files, might still be nice?

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

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 23 Jun 2003 18:03:51 -0500

The problem with this is that this "unix" may not be the same as that
"unix" in this or other respects.  This particular behavior is a Unix
SVID behavior and not a *BSD behavior.  I would consider it perfectly
reasonable for a *BSD NFSv4 server to not support the SGID/mandatory
file locking semantics.

This specific scenario points to the larger, long term issue of how
does an application determine the support available to it.  Even if
the application can determine it is operating on files via NFSv4, how
does it query for available support for this and other mechanisms
(e.g. ACL support).

While we have provided flexibility in the protocol for varying client
and server environments, we have not discussed the method of providing
capabilities between client/server/applications, etc.

In this specific case, the applications best choice is to use file
locking and assume it is advisory in nature.

Spencer

-- 
Spencer

---

From: Erblichs <[email-masked]>
Date: Mon, 23 Jun 2003 17:27:21 -0700

Grooup,

	Why not create use two behaviours that downgrades (mandatory
	to advisory) or upgrades (advisory to mandatory) behaviour
	based on some credentials field when accessing a file
	object or server support of mandatory locking?

	I would then think it would allowable for apps to assume
	mandatory locking.

	If their is a concern for legacy interoperability, then
	create new "calls" that "aware applications" can use and
	set a timeframe to obsolete the old interface.

	I thought this type of work was done in the past with NFSv3?

	Mitchell Erblich
	Sr Software Engineer

	------------------------

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 23 Jun 2003 19:43:17 -0500

> 	I would then think it would allowable for apps to assume

If there is consensus that mandatory file locking should be a
mandatory feature of the protocol, then this may work.

> 	set a timeframe to obsolete the old interface.

The main issue with this is the application's ability to obtain what
type of file system is being used and in this case what minor version
of NFSv4 is being used between client/server.  

All of this assumes that applications need/use file locking as a
method of file data access control and that they also require
mandatory file locking to keep our access that is not well behaved.

Spencer

---

From: David Robinson <[email-masked]>
Date: Wed, 25 Jun 2003 16:00:40 -0500

> reasonable for a *BSD NFSv4 server to not support the SGID/mandatory

Be very careful on this one, SVID3 mandatory
locking semantics are not the same as NFSv4 (or Windows) mandatory
locking.  The critical difference is that SVID requires that the
I/O operation block until the lock is released, NFSv4 will cause an
error to be returned. To effectively implement this a server must
change its behavior to not block I/O requests and to return an
error (or face dire consequences when a request is retransmitted)
and the client must continuously retry the request will blocking
the system call. There may be subtle timing or ordering issues
about who gets the next I/O that will break using a polling model.
Lastly, an open with O_TRUNC on a file with a SVID3 mandatory lock
must fail with EAGAIN.  This may not be possible.

In short, the text should have been written to state:

	Note that in Unix SVID3, if a file has the MODE4_SGID bit set
	and no 	MODE4_XGRP bit set, then SVID3 mandatory file locking
	semantics may apply. SVID3 mandatory locking semantics are not
	the same as NFSv4 semantics and the mapping between the two is
	undefined and may vary based on implementation. Some
	implementations may not allow any access to these files.

If anyone wants to try and figure out a reasonable mapping as a
suggested implementation... I don't think many applications rely
on SVID3 locking semantics.

	-David