[nfsv4] Migration questions

Chenggong Fan <fan@rainfinity.com> Sat, 09 October 2004 21:04 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09727 for <nfsv4-web-archive@ietf.org>; Sat, 9 Oct 2004 17:04:58 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGOYu-0005ki-Af for nfsv4-web-archive@ietf.org; Sat, 09 Oct 2004 17:15:32 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGOKB-0002JY-RM; Sat, 09 Oct 2004 17:00:19 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGOJ9-00028C-Ig for nfsv4@megatron.ietf.org; Sat, 09 Oct 2004 16:59:15 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09213 for <nfsv4@ietf.org>; Sat, 9 Oct 2004 16:59:13 -0400 (EDT)
Received: from mail1.rainfinity.com ([128.242.125.75]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGOTL-0005fM-S6 for nfsv4@ietf.org; Sat, 09 Oct 2004 17:09:48 -0400
Received: from localhost (localhost.rainfinity.com [127.0.0.1]) by mail1.rainfinity.com (Postfix) with ESMTP id C14B0104167; Sat, 9 Oct 2004 13:59:14 -0700 (PDT)
Received: from mail1.rainfinity.com ([127.0.0.1]) by localhost (mail1.rainfinity.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08847-24; Sat, 9 Oct 2004 13:59:14 -0700 (PDT)
Received: from rainfinity.com (adsl-69-104-244-13.dsl.pltn13.pacbell.net [69.104.244.13]) by mail1.rainfinity.com (Postfix) with ESMTP id 0CE081040FA; Sat, 9 Oct 2004 13:59:14 -0700 (PDT)
Message-ID: <416850AB.5010103@rainfinity.com>
Date: Sat, 09 Oct 2004 13:57:15 -0700
From: Chenggong Fan <fan@rainfinity.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: nfsv4@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at rainfinity.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Content-Transfer-Encoding: 7bit
Subject: [nfsv4] Migration questions
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/nfsv4>
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>
Sender: nfsv4-bounces@ietf.org
Errors-To: nfsv4-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Content-Transfer-Encoding: 7bit

Hi,

I have some questions related to the management of file handles after 
receiving NFS4ERR_MOVED in the migration case (not the pure referral 
case). 

If a file handle is not a volatile file handle, currently the NFSv4 
client does not remember the associated pathname with each file handle, 
correct?  If that's the case, it seems difficult to make the 
NFS4ERR_MOVED and GETATTR fs_location useful in the migration case.

Let's say the client has been accessing this filesystem for a while, and 
suddenly it gets the MOVED error.  Without the associated pathname, how 
would the client be able to use fs_location information to look up the 
new file handle in the new file system?   With filehandle being an 
opaque object, the client shouldn't just replace the fsid field in the 
file handle.  It seems that for migration to work, all file handles need 
to be volatile, (or in other words, client need to keep track of 
pathnames associated with all the file handles it knows)?   Is it too 
much a load on the client?

Second, what should the client do to the other file handles that have 
the same fsid?  Should it not do anything about them?  Or should it 
expire all of them?  If the first case, the access to each fh will get a 
separate MOVED error, and the scenario is the same as the last 
paragraph.  If this is the case, file-level referral actually might be 
possible.  If the second case, again the client needed to remember the 
pathname to look up the new file handles in the new filesystem, or all 
file handles will be stale.

After all it looks that "pure referral" might be easier to support than 
migration redirection.  Am I missing anything?

Charles

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