Subject: Re: [nfsv4] Global namespace for v4.1?

From: Jim Rees <[email-masked]>
Date: Tue, 09 Dec 2003 19:24:14 -0500

While I agree we shouldn't be inventing a new name service or database, I
worry that if NFSv4 gets too big it will collapse under its own weight the
way DCE/DFS did.  I don't think we should require clients to have an LDAP
client to work in the global file system.

Maybe a compromise would be to have the servers do the LDAP query on behalf
of the client.

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

---

From: "Sukanta Ganguly" <[email-masked]>
Date: Wed, 10 Dec 2003 10:45:51 -0800

Hi,
   LDAP is getting to be on every desktop/laptop that is shipped today and I think that is true for most of the common OS's so LDAP may not be a bad choice. However, I think a seperate server-server and client-server discovery should be defined from a pure NFS v2 extension or somthing in that nature. We should not depend on it being an LDAP only element.
   So I think work on both the front needs to happen and I would like to Volunteer. The only problem is I will be out for the next 10 days but can start actively after that. 
   Is that OK?
 
SG

	-----Original Message----- 
	From: Noveck, Dave [mailto:[email-masked]] 
	Sent: Wed 12/10/2003 7:23 AM 
	To: Jim Rees; [email-masked] 
	Cc: 
	Subject: RE: [nfsv4] Global namespace for v4.1? 

	I think we need to separately consider the client-server part of this, from
	the server-server part, and if we do that, we have a lot of choices, including
	the one you suggest below.
	
	With regard to the server-server part, I have no strong opinions either
	way.  I didn't suggest something LDAP-related because of my lack of LDAP
	knowledge.  If someone wants to specify this in terms of LDAP, I have
	no problem.  If someone wants to do this as a separate server-sever protocol,
	I don't have a problem either.  If someone wants to do this as small extensions
	to v4 (e.g. op to list a server's fs's, etc.), still no problem.  If none
	of the above, then I do have a problem but not one I can do anything about,
	so we'll just let that slide.
	
	With regard to the client-server part, the basic issue is that Brent's
	approach is a ton of more work, and I'd prefer to limit the work involved,
	particularly my own.  In addition to the every-nfs-client-has-to-have-an-
	LDAP-client-as-well issue that Jim identified, a number of other things
	become a whole lot more work.  The basic issue is that clients already
	have to deal with MOVED and getting a referral to a different location.
	Does it make sense for them to have that facility but use it only rarely,
	as Brent suggest, or instead use it for a wider range of circumstances,
	in particular, for those in which the fs sought is at a different
	location and was never actually served at its nominal address?  As far
	as the actual work of writing the I-D (which is what concerns me right now)
	there's the same issue.  The mechanism for a client to be directed to
	another location is already defined.  The only thing that has to change
	is that the server should be encouraged to return fsid and well as fs_locations,
	to deal with the case of crossing into the root of an absent fs.  This
	would make server presentation of a global namespace feasible but it
	really should be done anyway, since even in the pure fs motion case (no
	global namespace), the possiblity of crossing into an absent fs does
	exist.
	
	The other thing that makes this approach desirable is that, we can get
	going on it, without waiting for v4.1.  The existing spec suggests the
	server will only return fs_locations but it desn't forbid returning
	other attributes (e.g. fsid) as well.  So here's a notice for Connectathon
	participants.  I will have some servers set up so that you will cross
	into an absent fs, and be redirected to another server.  Clients are
	encouraged to interrogate fsid as well as fs_locations continue the
	mount as if nothing is wrong, and nothing will be wrong.
	
	When someone specifies the LDAP database to store this stuff, if that
	happens, I will modify my server to get the location data out of that,
	thus implementing Jim's compromise.  Now all we need is a volunteer to
	specify that LDAP, or the server-server protocol, or v4.1 fs discovery
	extensions.  Any of the above work for me.  Volunteers?
	
	-----Original Message-----
	From: Jim Rees [mailto:[email-masked]]
	Sent: Tuesday, December 09, 2003 7:24 PM
	To: [email-masked]
	Subject: Re: [nfsv4] Global namespace for v4.1?

	

'~������x%��g~����_��!��l��0�X���+����Y���b�ا~��~��

---

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 11 Dec 2003 07:00:16 -0800

Duh!  I had forgotten that Rob had written an I-D on this subject.
Thanks for the pointer.

I don't have any big objection to a separate referral error if
people want it in v4.1.  Maybe the extra information might be 
helpful in some cases.  But I think that if we can do this with
no protocol change whatever in v4.0 (see my query about fs_root),
then that is by far the best alternative, with the possiblity
that we could be mounting ntap1:/locations/sun/v4test1 and
be directed to sun1:/public/test, at conectathon.  Actually,
I'd prefer to be working on that kind of prototype than arguing
about LDAP vs. something else.

As Ted suggests, as that activity develops, we can easily hook
up a referral filesystem to whatever people decide is the 
right way to do this.

-----Original Message-----
From: Ted Anderson [mailto:[email-masked]]
Sent: Thursday, December 11, 2003 8:23 AM
To: [email-masked]
Cc: Juan Gomez
Subject: Re: [nfsv4] Global namespace for v4.1?

On 12/10/2003 14:17, Juan Gomez wrote:
> I think not re-inventing things that are out there is good. The only
> problem I see with this is configuration. You now need to make sure that
> your v4 servers are well aware of where to go when the FS is not where it
> must be. I know there are other protocols that can help you there but then
> you add a lot of dependencies so it boils down to dependencies and one-time
> install /configuration work as opposed to have a self-contained system
> where v4 covers everything from location mapping to NFS functionality.

One approach that has been suggested by Rob Thurlow in his namespace 
I/D[1], and which Dave mentioned at the beginning of this thread, is to 
  utilize NFSv4 as a namespace protocol.  In this approach, a NFSv4 
server acts as a wrapper or proxy for some other name service(s), such 
as LDAP or DNS, but always identifies filesystems as MOVED to their 
current homes.  This allows the NFSv4 client to use the same protocol to 
traverse the namespace as to access files.  This NFSv4 name server could 
be centrally located in each organization.  Or more globally, there 
could be a network of these servers addressing different collaborative 
scales (inter-organizational, organization, department, etc) directing 
clients from one to another until a "leaf" filesystem was identified. 
Possibly, if the NFSv4 name server is really only a proxy for one or 
more name services, then you could also choose to run one on each 
machine as a namespace helper application.  Clearly, there are different 
trade-offs to be explored regarding various configuration and managment 
issues.

Ted Anderson

[1] http://www.ietf.org/internet-drafts/draft-thurlow-nfsv4-namespace-00.txt

---

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 11 Dec 2003 09:01:55 -0800

SSBkb24ndCBrbm93IGlmIGEgdGVuLWRheSBkZWxheSB3b3VsZCBwdXQgaXQgb3V0c2lkZSB2NC4xLiAgT25seQ0KU3BlbmNlciBhbmQgQmVlcHkgY2FuIGFuc3dlciB0aGF0LCBhbmQgSSdtIGd1ZXNzaW5nIHRoZWlyIGFuc3dlcg0Kd291bGQgYmUgIml0IGRlcGVuZHMiLiAgTXkgYWR2aWNlIHdvdWxkIGJlIG5vdCB0byBsZXQgdGhhdCBiZQ0KdGhlIGJpZyBpc3N1ZS4gIEl0J3MgZWFzeSB0byBzYXksICJJZiBpdCBjYW4ndCBnZXQgaW50byB2NC4xLCANCkkgY2FuIHN0YXJ0IGxhdGVyIiBidXQgd2hhdCB0ZW5kcyB0byBoYXBwZW4gd2l0aCBtZSBhdCBsZWFzdCANCmlzIHRoYXQgSSBkZWxheSBhbmQgd2luZCB1cCBpbiB0aGUgc2FtZSBzaXR1YXRpb24gd2hlbiB0aGUgbmV4dCANCmRlYWRsaW5lIChlLmcuIGZvciB2NC4yKSBnZXRzIHJlYWR5IHRvIGhhcHBlbi4NCg0KU28gbXkgYWR2aWNlIHdvdWxkIGJlIHRvIGdvIGZvciBpdCBhbmQgbWFrZSBwcm9nZXNzIG9uIHRoZSBpc3N1ZSwNCmFuZCBsZXQgdGhlIG1pbm9yIHZlcnNpb24gZGVhZGxpbmVzIGZhbGwgd2hlcmUgdGhleSBtYXkuDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFN1a2FudGEgR2FuZ3VseSBbbWFpbHRvOmdhbmd1bHlAaW9tZWdhLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgRGVjZW1iZXIgMTAsIDIwMDMgMTo0NiBQTQ0KVG86IE5vdmVjaywgRGF2ZTsgSmltIFJlZXM7IG5mc3Y0QGlldGYub3JnDQpTdWJqZWN0OiBSRTogW25mc3Y0XSBHbG9iYWwgbmFtZXNwYWNlIGZvciB2NC4xPw0KDQoNCkhpLA0KICAgTERBUCBpcyBnZXR0aW5nIHRvIGJlIG9uIGV2ZXJ5IGRlc2t0b3AvbGFwdG9wIHRoYXQgaXMgc2hpcHBlZCB0b2RheSBhbmQgSSB0aGluayB0aGF0IGlzIHRydWUgZm9yIG1vc3Qgb2YgdGhlIGNvbW1vbiBPUydzIHNvIExEQVAgbWF5IG5vdCBiZSBhIGJhZCBjaG9pY2UuIEhvd2V2ZXIsIEkgdGhpbmsgYSBzZXBlcmF0ZSBzZXJ2ZXItc2VydmVyIGFuZCBjbGllbnQtc2VydmVyIGRpc2NvdmVyeSBzaG91bGQgYmUgZGVmaW5lZCBmcm9tIGEgcHVyZSBORlMgdjIgZXh0ZW5zaW9uIG9yIHNvbXRoaW5nIGluIHRoYXQgbmF0dXJlLiBXZSBzaG91bGQgbm90IGRlcGVuZCBvbiBpdCBiZWluZyBhbiBMREFQIG9ubHkgZWxlbWVudC4NCiAgIFNvIEkgdGhpbmsgd29yayBvbiBib3RoIHRoZSBmcm9udCBuZWVkcyB0byBoYXBwZW4gYW5kIEkgd291bGQgbGlrZSB0byBWb2x1bnRlZXIuIFRoZSBvbmx5IHByb2JsZW0gaXMgSSB3aWxsIGJlIG91dCBmb3IgdGhlIG5leHQgMTAgZGF5cyBidXQgY2FuIHN0YXJ0IGFjdGl2ZWx5IGFmdGVyIHRoYXQuIA0KICAgSXMgdGhhdCBPSz8NCiANClNHDQogDQoNCgktLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSANCglGcm9tOiBOb3ZlY2ssIERhdmUgW21haWx0bzpEYXZlLk5vdmVja0BuZXRhcHAuY29tXSANCglTZW50OiBXZWQgMTIvMTAvMjAwMyA3OjIzIEFNIA0KCVRvOiBKaW0gUmVlczsgbmZzdjRAaWV0Zi5vcmcgDQoJQ2M6IA0KCVN1YmplY3Q6IFJFOiBbbmZzdjRdIEdsb2JhbCBuYW1lc3BhY2UgZm9yIHY0LjE/IA0KCQ0KCQ0KDQoJSSB0aGluayB3ZSBuZWVkIHRvIHNlcGFyYXRlbHkgY29uc2lkZXIgdGhlIGNsaWVudC1zZXJ2ZXIgcGFydCBvZiB0aGlzLCBmcm9tDQoJdGhlIHNlcnZlci1zZXJ2ZXIgcGFydCwgYW5kIGlmIHdlIGRvIHRoYXQsIHdlIGhhdmUgYSBsb3Qgb2YgY2hvaWNlcywgaW5jbHVkaW5nDQoJdGhlIG9uZSB5b3Ugc3VnZ2VzdCBiZWxvdy4NCgkNCglXaXRoIHJlZ2FyZCB0byB0aGUgc2VydmVyLXNlcnZlciBwYXJ0LCBJIGhhdmUgbm8gc3Ryb25nIG9waW5pb25zIGVpdGhlcg0KCXdheS4gIEkgZGlkbid0IHN1Z2dlc3Qgc29tZXRoaW5nIExEQVAtcmVsYXRlZCBiZWNhdXNlIG9mIG15IGxhY2sgb2YgTERBUA0KCWtub3dsZWRnZS4gIElmIHNvbWVvbmUgd2FudHMgdG8gc3BlY2lmeSB0aGlzIGluIHRlcm1zIG9mIExEQVAsIEkgaGF2ZQ0KCW5vIHByb2JsZW0uICBJZiBzb21lb25lIHdhbnRzIHRvIGRvIHRoaXMgYXMgYSBzZXBhcmF0ZSBzZXJ2ZXItc2V2ZXIgcHJvdG9jb2wsDQoJSSBkb24ndCBoYXZlIGEgcHJvYmxlbSBlaXRoZXIuICBJZiBzb21lb25lIHdhbnRzIHRvIGRvIHRoaXMgYXMgc21hbGwgZXh0ZW5zaW9ucw0KCXRvIHY0IChlLmcuIG9wIHRvIGxpc3QgYSBzZXJ2ZXIncyBmcydzLCBldGMuKSwgc3RpbGwgbm8gcHJvYmxlbS4gIElmIG5vbmUNCglvZiB0aGUgYWJvdmUsIHRoZW4gSSBkbyBoYXZlIGEgcHJvYmxlbSBidXQgbm90IG9uZSBJIGNhbiBkbyBhbnl0aGluZyBhYm91dCwNCglzbyB3ZSdsbCBqdXN0IGxldCB0aGF0IHNsaWRlLg0KCQ0KCVdpdGggcmVnYXJkIHRvIHRoZSBjbGllbnQtc2VydmVyIHBhcnQsIHRoZSBiYXNpYyBpc3N1ZSBpcyB0aGF0IEJyZW50J3MNCglhcHByb2FjaCBpcyBhIHRvbiBvZiBtb3JlIHdvcmssIGFuZCBJJ2QgcHJlZmVyIHRvIGxpbWl0IHRoZSB3b3JrIGludm9sdmVkLA0KCXBhcnRpY3VsYXJseSBteSBvd24uICBJbiBhZGRpdGlvbiB0byB0aGUgZXZlcnktbmZzLWNsaWVudC1oYXMtdG8taGF2ZS1hbi0NCglMREFQLWNsaWVudC1hcy13ZWxsIGlzc3VlIHRoYXQgSmltIGlkZW50aWZpZWQsIGEgbnVtYmVyIG9mIG90aGVyIHRoaW5ncw0KCWJlY29tZSBhIHdob2xlIGxvdCBtb3JlIHdvcmsuICBUaGUgYmFzaWMgaXNzdWUgaXMgdGhhdCBjbGllbnRzIGFscmVhZHkNCgloYXZlIHRvIGRlYWwgd2l0aCBNT1ZFRCBhbmQgZ2V0dGluZyBhIHJlZmVycmFsIHRvIGEgZGlmZmVyZW50IGxvY2F0aW9uLg0KCURvZXMgaXQgbWFrZSBzZW5zZSBmb3IgdGhlbSB0byBoYXZlIHRoYXQgZmFjaWxpdHkgYnV0IHVzZSBpdCBvbmx5IHJhcmVseSwNCglhcyBCcmVudCBzdWdnZXN0LCBvciBpbnN0ZWFkIHVzZSBpdCBmb3IgYSB3aWRlciByYW5nZSBvZiBjaXJjdW1zdGFuY2VzLA0KCWluIHBhcnRpY3VsYXIsIGZvciB0aG9zZSBpbiB3aGljaCB0aGUgZnMgc291Z2h0IGlzIGF0IGEgZGlmZmVyZW50DQoJbG9jYXRpb24gYW5kIHdhcyBuZXZlciBhY3R1YWxseSBzZXJ2ZWQgYXQgaXRzIG5vbWluYWwgYWRkcmVzcz8gIEFzIGZhcg0KCWFzIHRoZSBhY3R1YWwgd29yayBvZiB3cml0aW5nIHRoZSBJLUQgKHdoaWNoIGlzIHdoYXQgY29uY2VybnMgbWUgcmlnaHQgbm93KQ0KCXRoZXJlJ3MgdGhlIHNhbWUgaXNzdWUuICBUaGUgbWVjaGFuaXNtIGZvciBhIGNsaWVudCB0byBiZSBkaXJlY3RlZCB0bw0KCWFub3RoZXIgbG9jYXRpb24gaXMgYWxyZWFkeSBkZWZpbmVkLiAgVGhlIG9ubHkgdGhpbmcgdGhhdCBoYXMgdG8gY2hhbmdlDQoJaXMgdGhhdCB0aGUgc2VydmVyIHNob3VsZCBiZSBlbmNvdXJhZ2VkIHRvIHJldHVybiBmc2lkIGFuZCB3ZWxsIGFzIGZzX2xvY2F0aW9ucywNCgl0byBkZWFsIHdpdGggdGhlIGNhc2Ugb2YgY3Jvc3NpbmcgaW50byB0aGUgcm9vdCBvZiBhbiBhYnNlbnQgZnMuICBUaGlzDQoJd291bGQgbWFrZSBzZXJ2ZXIgcHJlc2VudGF0aW9uIG9mIGEgZ2xvYmFsIG5hbWVzcGFjZSBmZWFzaWJsZSBidXQgaXQNCglyZWFsbHkgc2hvdWxkIGJlIGRvbmUgYW55d2F5LCBzaW5jZSBldmVuIGluIHRoZSBwdXJlIGZzIG1vdGlvbiBjYXNlIChubw0KCWdsb2JhbCBuYW1lc3BhY2UpLCB0aGUgcG9zc2libGl0eSBvZiBjcm9zc2luZyBpbnRvIGFuIGFic2VudCBmcyBkb2VzDQoJZXhpc3QuDQoJDQoJVGhlIG90aGVyIHRoaW5nIHRoYXQgbWFrZXMgdGhpcyBhcHByb2FjaCBkZXNpcmFibGUgaXMgdGhhdCwgd2UgY2FuIGdldA0KCWdvaW5nIG9uIGl0LCB3aXRob3V0IHdhaXRpbmcgZm9yIHY0LjEuICBUaGUgZXhpc3Rpbmcgc3BlYyBzdWdnZXN0cyB0aGUNCglzZXJ2ZXIgd2lsbCBvbmx5IHJldHVybiBmc19sb2NhdGlvbnMgYnV0IGl0IGRlc24ndCBmb3JiaWQgcmV0dXJuaW5nDQoJb3RoZXIgYXR0cmlidXRlcyAoZS5nLiBmc2lkKSBhcyB3ZWxsLiAgU28gaGVyZSdzIGEgbm90aWNlIGZvciBDb25uZWN0YXRob24NCglwYXJ0aWNpcGFudHMuICBJIHdpbGwgaGF2ZSBzb21lIHNlcnZlcnMgc2V0IHVwIHNvIHRoYXQgeW91IHdpbGwgY3Jvc3MNCglpbnRvIGFuIGFic2VudCBmcywgYW5kIGJlIHJlZGlyZWN0ZWQgdG8gYW5vdGhlciBzZXJ2ZXIuICBDbGllbnRzIGFyZQ0KCWVuY291cmFnZWQgdG8gaW50ZXJyb2dhdGUgZnNpZCBhcyB3ZWxsIGFzIGZzX2xvY2F0aW9ucyBjb250aW51ZSB0aGUNCgltb3VudCBhcyBpZiBub3RoaW5nIGlzIHdyb25nLCBhbmQgbm90aGluZyB3aWxsIGJlIHdyb25nLg0KCQ0KCVdoZW4gc29tZW9uZSBzcGVjaWZpZXMgdGhlIExEQVAgZGF0YWJhc2UgdG8gc3RvcmUgdGhpcyBzdHVmZiwgaWYgdGhhdA0KCWhhcHBlbnMsIEkgd2lsbCBtb2RpZnkgbXkgc2VydmVyIHRvIGdldCB0aGUgbG9jYXRpb24gZGF0YSBvdXQgb2YgdGhhdCwNCgl0aHVzIGltcGxlbWVudGluZyBKaW0ncyBjb21wcm9taXNlLiAgTm93IGFsbCB3ZSBuZWVkIGlzIGEgdm9sdW50ZWVyIHRvDQoJc3BlY2lmeSB0aGF0IExEQVAsIG9yIHRoZSBzZXJ2ZXItc2VydmVyIHByb3RvY29sLCBvciB2NC4xIGZzIGRpc2NvdmVyeQ0KCWV4dGVuc2lvbnMuICBBbnkgb2YgdGhlIGFib3ZlIHdvcmsgZm9yIG1lLiAgVm9sdW50ZWVycz8NCgkNCgktLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KCUZyb206IEppbSBSZWVzIFttYWlsdG86cmVlc0B1bWljaC5lZHVdDQoJU2VudDogVHVlc2RheSwgRGVjZW1iZXIgMDksIDIwMDMgNzoyNCBQTQ0KCVRvOiBuZnN2NEBpZXRmLm9yZw0KCVN1YmplY3Q6IFJlOiBbbmZzdjRdIEdsb2JhbCBuYW1lc3BhY2UgZm9yIHY0LjE/DQoJDQoJDQoJV2hpbGUgSSBhZ3JlZSB3ZSBzaG91bGRuJ3QgYmUgaW52ZW50aW5nIGEgbmV3IG5hbWUgc2VydmljZSBvciBkYXRhYmFzZSwgSQ0KCXdvcnJ5IHRoYXQgaWYgTkZTdjQgZ2V0cyB0b28gYmlnIGl0IHdpbGwgY29sbGFwc2UgdW5kZXIgaXRzIG93biB3ZWlnaHQgdGhlDQoJd2F5IERDRS9ERlMgZGlkLiAgSSBkb24ndCB0aGluayB3ZSBzaG91bGQgcmVxdWlyZSBjbGllbnRzIHRvIGhhdmUgYW4gTERBUA0KCWNsaWVudCB0byB3b3JrIGluIHRoZSBnbG9iYWwgZmlsZSBzeXN0ZW0uDQoJDQoJTWF5YmUgYSBjb21wcm9taXNlIHdvdWxkIGJlIHRvIGhhdmUgdGhlIHNlcnZlcnMgZG8gdGhlIExEQVAgcXVlcnkgb24gYmVoYWxmDQoJb2YgdGhlIGNsaWVudC4NCgkNCglfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KCW5mc3Y0IG1haWxpbmcgbGlzdA0KCW5mc3Y0QGlldGYub3JnDQoJaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmZzdjQNCgkNCglfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KCW5mc3Y0IG1haWxpbmcgbGlzdA0KCW5mc3Y0QGlldGYub3JnDQoJaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmZzdjQNCgkNCg0K_______________________________________________nfsv4 mailing [email-masked]://www1.ietf.org/mailman/listinfo/nfsv4

---

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 15 Dec 2003 08:15:13 -0800

As I understand it, you are worried that clients are going to
expect the fsid to stay the same, on either referral or 
mirgration, and that some servers will try to accommodate 
such an expectation, resulting in an interoperability 
nightmare.  Am I understanding you correctly?  

I have trouble believing that such clients are likely to exist
and I certainly am not anticipating making any effort to 
accommodate them.  So at connectathon, expect the test case
of fsid changing to be in effect, both for migration and
referrals.  This is not as a result of a special effort
to provide a test case based on a Rob's problem description
and requirments, or the equivalent for migration. 

The reason I don't think it is likely that clients will 
find it difficult to adapt to fsid changes is that it they
are going to need their own mapping mechanism to their
own local fs identifier anyway.  There is nothing to prevent
multiple servers from having the same fsid's for different
filesystems so that clients, of necessity, map these to
their own fsid space, to report to applications.  That makes
it relatively easy to continue mapping the same fs with a 
different server-specified fsid to the same local fs 
identifier.

The area where I can see something analogous to what
you are worried about is fileid's.  There seem to be two
sorts of replication/migration implementations forseen.
One in which it anticipated that the target filesystem will 
have the same data, filename, etc. as the source, but not 
necessarily the same filehandles but expects the client to 
to remap volatile filehandles.  In the typical implementation
of that mode, you would expect fileids to change on the
migration event.  I'm not sure how clients would expect to
deal with the change of fileids in that event.  At least for
now, I expect only to deal with migration in which the target
fs is an exact copy of the source and so fileid's being 
different are not an issue.  Fileid's are probably not an
issue for referral in any case since there is no source 
fielid for anything at the source of the referral and thus
no possible conflict with any fileid on the target.

-----Original Message-----
From: Ted Anderson [mailto:[email-masked]]
Sent: Monday, December 15, 2003 10:06 AM
To: Noveck, Dave
Cc: Nicolas Williams; [email-masked]
Subject: Re: [nfsv4] Global namespace for v4.1?

On 12/12/2003 13:13, Noveck, Dave wrote:
>>I don't.  Fsid in practice is often derived from information that is
>>really private to the server that's serving the associated files.  In
>>fact, the very design of fsid parallels the *nix major/minor device
>>number idea (why? why was opaque not good enough?), and I think I won't
>>be the only one here not wanting fsid's to be cached elsewhere.
> 
> The v4 spec makes looking for fsid changes within a given server the
> way to see that you have crossed into a new fs.  That's the only
> use of fsid that makes sense.  There is no need to use it outside
> the boundaries of a given server.  It would have probably been better
> if we simply had a this-is-the-root-of-an-fs attribute, and not had
> fsid explicit in the protocol.

It is all well and good for you to say this here in a message buried in 
a long thread on namespaces, but this interpretation seems at best 
implicit in the spec.  I would expect that many clients will build the 
server fsid deep and hard into their implementations, which will prevent 
them from working with servers that support migration and perhaps 
referrals.  So servers will have to construct fsid mapping mechanisms to 
work-around these clients which will lead to mysterious interoperability 
problems.

This is where the connectathon can highlight where these assumptions 
have crept into the spec and various implementations.  Test cases at 
connectathon then depend upon the problem description and requirements 
mentioned Friday by Brent.

Ted Anderson

---

From: Mike Eisler <[email-masked]>
Date: Mon, 15 Dec 2003 16:39:37 -0800

> >  > Mode #1 is what Brent is advocating, and I agree that it
 > >  > will be very useful to have.  To some extent we can separate
 > >
 > > #1 is an evolutionary dead end.
 >
 > I disagree for a lot of reasons, but importantly we will

How many clients implementations implement a basic form of
replication support? One. And that client shipped in 96 or '97 and
it still doesn't issue an upcall to ask the automounter what the
new replica list is whenever it gets a server timeout.

Client side support for replication/migration namespace
would be useful and nice, but it will be a long time, if ever,
before it is ubiquitous. Whereas server vendors are motivated to
solve this if client implementors would focus on #2. A narrow form
of #2 would be very useful.

 > >  > back the same redirection information without causing
 > >  > an extra over the wire operation.
 > >
 > > fs_locations is an attribute.
 > > COMPOUND { ... LOOKUP ; GETFH; GETATTR fs_locations }
 > > does it one round trip.
 >
 > Nope. LOOKUP returns NFS4ERR_MOVED, according to the RFC
 > that indicates that the COMPOUND must terminate.  You can't
 > do either the GETFH or GETATTR. As I said before, LOOKUP
 > should be fixed.

Agreed.

---

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 22 Dec 2003 07:53:32 -0800

David Robinson wrote:  
> Rob Thurlow wrote:

> > - David's taxonomy of client and server capabilities
> >   was useful.  I tend to not see why folks like Brent
> >   and David want the client to consult the namespace
> >   repository directly - can someone tell me why that's
> >   a better architecture at all?  I know it's another
> >   step to have the server involved, but it's only
> >   another cache, and I think we can do that.  I am
> >   obviously sympathetic to the idea that if we have
> >   to implement migration anyway, we should use that
> >   mechanism to do namespace referrals as well, and
> >   I don't recognize a trigger that says that that's
> >   not good enough for a smarter client.

> Here is an alternative viewpoint. If we are going to
> provide server based referals within the namespace, servers
> will need to have some place to store and retrieve what
> referals exist, where they are in the global namespace,
> and where they point to.  This repository needs a
> standard set of semantics and a standard access method,
> otherwise you will only be able to handle a homogenous
> set of servers. Another way to put this is that the
> NFS servers are clients of the namespace.

> If we have standardized the namespace information, then
> it is relatively simple for a smart client to directly
> query it and skip the need to use the server for a
> referral.  This may help environments where there are
> many referrals or the NFS latency is high.

The question is "Why do it that way"?  I see that a client
could do this, but I don't see any likely advantage, and
certainly no reason to create a client intelligence hierarchy
in which NFSv4 clients that focus on the nfs-v4 protocol rate 
as stupider than those that make things more complicated by
implementing multiple protocols.

Now as to the statement "This may help environments where there 
are many referrals or the NFS latency is high.", while it MAY under
some (fairly unlikely in my opinion) circumstances, my guess
is that actual implementations of this won't happen unless
one knows it WILL help significantly in common circumstances.

I can't see anyone investing effort in such a thing unless, all
three of the following held, in a significant number of circumstances:

a) NFS latency is high
b) The latency of accessing the information through this other
   protocol (TBD) is significantly less
c) Referrals are a significant fraction of NFS request (i.e. are
   not in the noise)

To start with, environments in which c) is not the case are liable
to be pretty unusual.  How many fs's does one reference of which one
makes less than one hundred NFS requests?  They happen, sure, but
how many where you make less than ten?  Even fewer.  If NFS latency
is high, NFS access is going to be slow and the referral part (unless
referral servers have been placed very badly), is the least of it.
If you want to improve the situation would you invest client smarts in
better caching/delegation support or cutting the NFS server out of the
referral loop?

Also, if NFS latency is high, it is generally because you are far away
from the servers.  It might be the case that the servers for the new
protocol just happen to be a lot closer but most likely they're in the
same data center.  So I wouldn't normally expect better performance.
When this new protocol is selected, we can see.

One other answer to a cost of getting referral information is normal
caching.  A client can do a READDIR of stuff in the referral server's
pseudofs, fetching fsid and fs_locations and cache that.  I would
expect a v4 server running in referral mode to give you that
information if you asked for it (hope to do that for cthon but no
promises) so a "smart client" could just do READDIR's instead of LOOKUP's
(given high latency) and save the information for later use.  The nature
of referral information is that if there is a change and you act on 
outdated information, you'll probably be directed to the correct place,
find a non-responsive server, or an fs not present on the server and 
so in that case refetch from the referral server.  Referrals are, of
neceassity, not going to be such that the fs_locations you get, when
used, could designate the wrong fs.  This is because, when you get
fs_locations because of a referral or migration, there is no bound on
the time before you use it.  So this essentially requires that the 
fs_locations values returned never be reused in a fashion that could
cause mis-direction (and since they're of variable length, uniqueness
is easy to do).  So safe caching of referral information gets a free
ride on that basic structural fact about fs_locations values.   

> But I think if we adequately design the semantics of
> the repository and its access protocol, that is 99.44% of
> what a smart client will need.

> So I don't think we need to dwell on the smart client case
> (#1 in my taxonomy), if we do the rest well it should
> fall out almost for free.

Almost for free, yes.  Certainly as compared to lots of other
sorts of implementation.  But I still don't think the cost will
be low enough that people will actually bother doing the
implementation.

The state of affairs is we have a way (the dumb client way, if
you insist) to do this now, and it makes sense to implement that.
The new protocol has not been selected yet, so that implementing
client support for that is going to be an incremental cost and
I'm guessing the payoff will not be enough to justify that cost,
even though the cost is not all that large.