From: Chenggong Fan (fan@rainfinity.com)
Date: 10/09/04-03:57:15 PM Z
Message-ID: <416850AB.5010103@rainfinity.com> Date: Sat, 09 Oct 2004 13:57:15 -0700 From: Chenggong Fan <fan@rainfinity.com> Subject: [nfsv4] Migration questions 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
This archive was generated by hypermail 2.1.2 : 03/04/05-02:13:31 AM Z CST