Subject: [nfsv4] Global Namespaces Chapters Review #1 - minutes

From: Trond Myklebust <[email-masked]>
Date: Tue, 24 Jul 2007 17:36:14 -0400

Note: Some of the attributions here may be incorrect. In particular, Dan
Ellard turned up late and failed to notify us when he did. Please check
attributions for correctness...

--------------------------------------------------
Mike Eisler		(NetApp)
Daniel Ellard		(NetApp)
Craig Everhart		(NetApp)	Reader
Trond Myklebust		(NetApp)	Scribe
Dave Noveck		(NetApp)	Author
Theresa Raj		(NetApp)

Renu Tewari		(IBM)

Robert Thurlow		(SUN)
Spencer Shepler		(SUN)		Moderator

Fred Isaman		(CITI)

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

Spencer kicked off the meeting with the usual cautions about
all your comments are belong to IETF.

-----------

7633	Everhart	Is it "Name Space" or "Namespace"?
	 		Both editors appear to prefer "namespace"
			Wikipedia appears to agree, so it must be true!

....Craig went off to print out Draft 11....

7681	Myklebust	To a first-time reader, it would not be obvious that
			this paragraph refers to NFSv2/v3. Perhaps a better
			strategy would be to discuss NFSv2/v3 first, then
			NFSv4?
	Thurlow		Join paragraphs 2 & 3?

-----

7710	Myklebust	Do you really require a unique fsid for each pseudo
			filesystem?
		Concensus is to retain the requirement but expand
		to a MUST.

	Thurlow		Can we have /a/b also be a pseudo-filesystem?
	Noveck		It cannot have symlinks etc.
	Eisler		Can you return fs_location?
		Consensus is no...
			Note that pseudo filesystem is there in order to bridge
			v2/v3 namespace and v4 namespace.
-----
7715	Everhart	Clarify the text to explain that the pseudo-filesystem
			solution is implementation advice, not normative.
			Toss out the words "DOS" and note that MacOS 9 is
			unlikely to ever implement a v4.1 server.
	Myklebust	MacOSX does not have this issue.
-----
7732	Ellard?		Delete section 7.5. It is obvious that
			pseudofilesystems may use volatile filehandles.
	Myklebust	Move this to the section on volatile filehandles? It is
			a major justification for implementing them.
	Noveck		Agrees.
-----
7754	Eisler		Convert archaic references to "disk" to "filesystem" in
			the examples.
----
7795	Myklebust	What is the recommended practice for dealing with
			LOOKUP/READDIR without confusing client caches?
			Should the pseudo-fs allow READDIR lookups for the
			entire shadowed directory?
			You cannot have both the pseudo-filesystem and the
			filesystem mounted, so if the server returns different
			filesystems based on security mechanism used by the user
			then that will confuse the client.
			Could we add text to clarify that this is not allowed?
	Noveck		You should use WRONGSEC to tell the user when to change
			security mechanism.
	Eisler		You should always return the same content.
		Consensus....
----
7823	Ellard?		Need clarification of this paragraph. The intention is
			that the client should always be able to traverse down
			to a given exported filesystem.
	Myklebust	The pseudofilesystem should always support all security
			mechanisms that are supported by the filesystems it is
			bridging.
	Eisler		You don't need to return the contents of the pathnames.
----
----
Chapter 10....
----
10665	Eisler		Attributes are recommended, so should multi-server name
			space be RECOMMENDED?
		Consensus is that use is "OPTIONAL", implementation is
		"RECOMMENDED"
----
10700	Thurlow		Why have both fs_status and fs_absent?
	Noveck		Histerical reasons... fs_absent should probably go...
		Consensus....
----
10786	Raj		Should we be using the change attribute to tell the
			client whether it can change policies such as referrals
			and secinfo?
	Myklebust	Could we please use a separate attribute to signify
			changes to policy?
		Consensus is that we can and should.
----
10790	Raj		What should the value of the fsid be?
	Noveck		Any value as long as it is unique.

	Thurlow		If the client has accessed a filesystem, will it
			observe that fsid change if the filesystem is migrated?
	Noveck		No, the fsid should not change.
	Myklebust	That would require the fsid to be stored somewhere.
		Consensus is this needs clarification
----
10837	Raj		The example at 12077 conflicts with this paragraph.
	Everhart	Deal with that later...
----
10957	Thurlow		The sentence starting "Where file systems are writable..."
			is unclear. Is the requirement too strong?
	Everhart	It is talking about the clustered case.

		Consensus is that entire section needs work...

	Everhart	Should writeable filesystems always be in sync?
	Noveck		That was indeed the intent.

		Need to take this to the lists....

	Myklebust	Does this apply to locks too?
		Needs further discussion.
----
11024	Ellard?		Is inconsistent with the discussion in 10957.
	Thurlow		Wording works better for me here.

11038	Everhart	What is the scope for the word "similar".
		Take this to the lists
----
11068	Everhart	This line is inconsistent with lines 11024 & 10957.
----
11076	Everhart	See the earlier discussion of RECOMMENDED vs OPTIONAL.
	Noveck		Agrees this para should reflect that.
----
11113	Myklebust	Is this an issue? The client needs to manage its own
			namespace anyway: it can never rely on the results of
			LOOKUPP in order to determine whether or not it is
			crossing a mountpoint.
			Move this to the more general point of mountpoint
			crossing?
	Eisler		The point is that the client may assume that whereas
			submounts of the replicated filesystem are the same,
			the parent namespace is not.
		Noveck will rewrite the paragraph to make Mike's point more
		apparent.

	Thurlow		Suggest adding a forward reference in the Single Server
			namespace chapter

			"Entries in a pseudofilesystem may be directories
			containing any of the following: referrals or the
			mountpoints of present filesystems."

		No consensus: take this to the lists.
----
11122	Ellard?		This paragraph really belongs under LOOKUPP. Nothing to do
			with referrals.
----
	Raj		Since migration/replication is OPTIONAL, there could be
			cases where the client doesn't support referrals. It
			would be useful for the server to know this.
	Eisler		EXCHANGE_ID already tells the server this info.
			We should add a reference.
----
	Everhart	Is there a time-to-live?
	Isaman		There is on 12628, but it doesn't refer to referrals.
	Myklebust	Is this a useful concept? The server can't offer
			promises on behalf of the administrator. We have no
			equivalent for any of our other caches.

		No consensus...
----

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

---

From: Trond Myklebust <[email-masked]>
Date: Tue, 24 Jul 2007 17:44:00 -0400

> attributions for correctness...

I should perhaps have pointed out here that the line numbers in these
minutes are all relative to Draft 11 of the NFSv4.1 spec since the
previous reviews have all been relative to draft 10...

Trond