Re: [nfsv4] Some stuff on referrals/migration

Brent Callaghan <brent@eng.sun.com> Wed, 19 May 2004 21:45 UTC

Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21391 for <nfsv4-archive@odin.ietf.org>; Wed, 19 May 2004 17:45:41 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQYf5-0002Hd-Ve for nfsv4-archive@odin.ietf.org; Wed, 19 May 2004 17:31:40 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4JLVdFS008765 for nfsv4-archive@odin.ietf.org; Wed, 19 May 2004 17:31:39 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQYP8-0002OZ-H7 for nfsv4-web-archive@optimus.ietf.org; Wed, 19 May 2004 17:15:10 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17811 for <nfsv4-web-archive@ietf.org>; Wed, 19 May 2004 17:15:01 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQYP0-0000wr-Va for nfsv4-web-archive@ietf.org; Wed, 19 May 2004 17:15:02 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQYO1-0000kQ-00 for nfsv4-web-archive@ietf.org; Wed, 19 May 2004 17:14:02 -0400
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQYMo-0000SZ-00 for nfsv4-web-archive@ietf.org; Wed, 19 May 2004 17:12:46 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQXT2-0005Xz-AD; Wed, 19 May 2004 16:15:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQXBb-0007Lw-BU for nfsv4@optimus.ietf.org; Wed, 19 May 2004 15:57:07 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09186 for <nfsv4@ietf.org>; Wed, 19 May 2004 15:57:05 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQXBZ-0003GP-Kz for nfsv4@ietf.org; Wed, 19 May 2004 15:57:05 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQXAi-00037l-00 for nfsv4@ietf.org; Wed, 19 May 2004 15:56:12 -0400
Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1BQX9k-0002u7-00 for nfsv4@ietf.org; Wed, 19 May 2004 15:55:13 -0400
Received: from jurassic.eng.sun.com ([129.146.89.50]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i4JJsgLr012176 for <nfsv4@ietf.org>; Wed, 19 May 2004 12:54:42 -0700 (PDT)
Received: from eng.sun.com (terra.SFBay.Sun.COM [129.146.86.99]) by jurassic.eng.sun.com (8.13.0.Beta2+Sun/8.13.0.Beta2) with ESMTP id i4JJsg46744322 for <nfsv4@ietf.org>; Wed, 19 May 2004 12:54:42 -0700 (PDT)
Message-ID: <40ABBB73.3000902@eng.sun.com>
From: Brent Callaghan <brent@eng.sun.com>
Reply-To: Brent.Callaghan@Sun.COM
Organization: Sun Microsystems
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.5b) Gecko/20030911
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: nfsv4@ietf.org
Subject: Re: [nfsv4] Some stuff on referrals/migration
References: <C8CF60CFC4D8A74E9945E32CF096548AB80DEE@silver.nane.netapp.com>
In-Reply-To: <C8CF60CFC4D8A74E9945E32CF096548AB80DEE@silver.nane.netapp.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: nfsv4-admin@ietf.org
Errors-To: nfsv4-admin@ietf.org
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/nfsv4/>
X-Original-Date: Wed, 19 May 2004 12:54:27 -0700
Date: Wed, 19 May 2004 12:54:27 -0700
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Given that fs_locations has been in the spec for several years
now, and we're still trying to figure out how to implement it,
is it time to re-evaluate it ?

The NFS4ERR_MOVED error looks useful, but the work
required to extract fs_locations data seems very complex.

NFS users already use referrals via global paths in symbolic
links, e.g. "foo -> /net/otherserver/foo". They can do this
today with NFSv2 and NFSv3. Symlinks have the nice property
that they can be manipulated as filesystem objects.  It's
not clear how an fs_location attribute would be represented
on a server.

It seems that you could implement most of fs_locations in
a symbolic link, perhaps by embedding an NFS URL in the
link text.  Would it be better to explore this further?

	Brent


Noveck, Dave wrote:
 > At various testing events I've promised to write up my thoughts
 > on how to do referrals in v4, using the existing migration
 > facility.  In many cases, I indicated that I would do it in a
 > few weeks.  Well weeks have turned into (many) months and still
 > no write-up.  Given that I'm going to see many of you at the
 > bakeathon, I've decided to avoid further embarrassment by just
 > doing what I said I would, even though quite a bit late.
 >
 > Attached are two html files.  The first is a kind of cookbook
 > that explains how I think referrals should happen and what the
 > client and server should each do about points that are not so
 > clear in RFC3530.  The second is broadly consistent with the
 > first (I hope) but has a different focus.  It explains how the
 > spec should be modified to be clearer about migration
 > implementation issues including referral.  Since RFC3530 is not
 > modifiable any more, the discussion is in terms of the spec for
 > v4.1, even though there are no actual changes to the protocol
 > (at least if one adopts the "correct" interpretation of v4.0,
 > i.e. mine, on any unclear points).


_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4