INTERNET-DRAFT David Noveck
Expires: January 2005 Network Appliance, Inc.
July 2004
Migration Issues for NFSv4
draft-noveck-nfsv4-migration-issues-00.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt The list of
Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Noveck Expires January 2005 [Page 1]
Internet-Draft Migration Issues for NFSv4 July 2004
Abstract
RFC3530 described an fs_locations attribute which can be used to
allow an fs to migrate between servers without disrupting client
access and to refer a client to another server providing access to
a specified file system. Initial implementation work for this
feature has exposed a number of areas where RFC3530's handling of
the issues leaves something to be desired. This document makes a
number of suggestions to remedy these issues when the NFSv4 spec
next undergoes a significant revision, most likely in connection
with implementing a new minor revision, such as NFSv4.1.
Table Of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
2. Attributes Returned by GETATTR and READDIR . . . . . . . . 2
3. Discussion of Error Codes . . . . . . . . . . . . . . . . 4
4. Issues of Incomplete Attribute Sets . . . . . . . . . . . 5
5. Referral Issues . . . . . . . . . . . . . . . . . . . . . 6
Acknowledgements . . . . . . . . . . . . . . . . . . . . . 15
Normative References . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . 15
Full Copyright Statement . . . . . . . . . . . . . . . . . 15
1. Introduction
Ongoing design work has exposed a number of weaknesses in the
discussion of migration within RFC 3530. While there does not
appear any necessity to change any message formats or add
operations, a number of migration-related issues should be
addressed when the protocol is updated for v4.1. The purpose of
this document is to clearly lay out what needs to be done, so that
any possible updates can be discussed as part of the process of
formulating a spec for v4.1. Some of the items discussed below
might also be appropriate in the context of an update of the NFSv4
spec in connection with going to a Draft Standard status.
2. Attributes Returned by GETATTR and READDIR
While the RFC3530 allows the server to return attributes in
addition to fs_locations, when GETATTR is used with a current
filehandle within an absent filesystem, not much guidance is given
to help clarify what is appropriate. In particular, there are a
number of attributes which most server implementations should find
relatively easy to supply which would be of value to clients,
Noveck Expires January 2005 [Page 2]
Internet-Draft Migration Issues for NFSv4 July 2004
particularly in those cases in which NFS4ERR_MOVED is returned when
first crossing into an absent file system that the client has not
referenced.
The NFSv4 spec should encourage servers to return the attributes
fsid and mounted_on_fileid for absent file systems. The specific
reasons will be discussed below.
On the other hand, a number of attributes pose difficulties when
returned for an absent filesystem. While not prohibiting the
server from returning these, the NFSv4 spec should explain the
issues which may result in problems, since these are not always
obvious. Handling of specific attributes is discussed below.
2.1. fsid
The fsid attribute allows clients to recognize when fs boundaries
have been crossed. This applies also when one crosses into an
absent filesystem. While returning fsid is not absolutely
required, since fs boundaries are also reflected, in this case, by
means of the fs_root field of the fs_locations attribute, returning
fsid is helpful and servers should have no difficulty in providing
it.
To avoid misunderstanding, any new NFSv4 RPC should note that the
fsid provided in this case is solely so that the fs boundaries can
be properly noted and that the fsid returned will not necessarily
be valid after resolution of the migration event. The logic of
fsid handling for NFSv4 is that fsid's are only unique within a
per-server context. This would seem to be a strong indication that
they need not be persistent when file systems are moved from server
to server, although RFC 3530 does not specifically address the
matter.
2.2. mounted_on_fileid
The mounted_on_fileid attribute is of particular importance to many
clients, in that they need this information to form a proper
response to a readdir() call. When a readdir() call is done within
UNIX, the d_ino field of each of the entries needs to have a unique
value normally derived from the NFSv4 fileid attribute. It is in
the case in which a file system boundary is crossed that using the
fileid attribute for this purpose, particularly when crossing into
an absent fs, will pose problems. Note first that the fileid
attribute, since it is within a new fs and thus a new fileid space,
will not be unique within the directory. Also, since the fs, at
its new location, may arrange things differently, the fileid
decided on at the directing server may be overridden at the target
Noveck Expires January 2005 [Page 3]
Internet-Draft Migration Issues for NFSv4 July 2004
server, making it of little value. Neither of these problems arise
in the case of mounted_on_fileid since that fileid is in the
context of the mounted-on fs and unique within it.
2.3. fileid
For reasons explained above under mounted_on_fileid, it would be
difficult for the referring server to provide a fileid value that
is of any use to the client. Given this, it seems much better for
the server never to return fileid values for files on an absent fs.
2.4. filehandle
Returning file handles for files in the absent fs, whether by use
of GETFH (discussed below) or by using the filehandle attribute
with GETATTR or READDIR poses problems for the client as the server
to which it is referred is likely not to assign the same filehandle
value to the object in question. Even though it is possible that
volatile filehandles may allow a change, the referring server
should not prejudge the issue of filehandle volatility for the
server which actually has the fs. By not providing the file
handle, the referring server allows the target server freedom to
choose the file handle value without constraint.
3. Discussion of Error Codes
There are a number of cases in which RFC 3530 is either unclear or
simply incorrect about the situations in which NFS4ERR_MOVED is to
be returned. Discussion of these issues has exposed the following
problems, which should be addressed to provide greater clarity and
correctness:
3.1. Issue of when to check current filehandle
In providing the definition of NFS4ERR_MOVED, RFC 3530 refers to
the "filesystem which contains the current filehandle object" being
moved to another server. This has led to some confusion when
considering the case of operations which change the current
filehandle and potentially the current file system. For example, a
LOOKUP which causes a transition to an absent file system might be
supposed to result in this error. This should be clarified to make
it explicit that only the current filehandle at the start of the
operation can result in NFS4ERR_MOVED.
3.2. Issue of GETFH
While RFC 3530 does not make any exception for GETFH when the
current filehandle is within an absent filesystem, the fact that
Noveck Expires January 2005 [Page 4]
Internet-Draft Migration Issues for NFSv4 July 2004
GETFH is such a passive, purely interrogative operation, may lead
readers to wrongly suppose that an NFSERR_MOVED error will not
arise in this situation. Any new NFSv4 RFC should explicitly state
that GETFH will return this error if the current filehandle is
within an absent filesystem.
3.3. Inconsistent handling of PUTFH
While RFC 3530 states (in section 6.2) "The NFS4ERR_MOVED error is
returned for all operations except PUTFH and GETATTR." Despite
this, RFC 3530 lists NFS4ERR_MOVED as an error that can be returned
by PUTFH. Any new NFSv4 RFC should delete this as a possible error
for PUTFH.
3.4. Inconsistent handling of GETATTR
While, as noted above, RFC 3530 indicates that NFS4ERR_MOVED is not
returned for a GETATTR operation, NFS4ERR_MOVED is listed as an
error that can be returned by GETATTR. It seems reasonable to
allow NFS4ERR_MOVED to be returned by GETATTR's that do not
interrogate the fs_locations attribute while maintaining the
exception which allows GETATTR to be used to get fs_locations
information by establishing the rules that GETATTR's which
interrogate fs_locations (with or without additional attributes)
will not return NFS4ERR_MOVED.
4. Issues of Incomplete Attribute Sets
Migration or referral events naturally create situations in which
all of the attributes normally supported on a server are not
obtainable. RFC3530 is in places ambivalent and/or apparently
self-contradictory on such issues. Any new NFSv4 RFC should take a
clear position on these issues (and it should not impose undue
difficulties on support for migration).
The first problem concerns the statement in the third paragraph of
section 6.2: "If the client requests more attributes than just
fs_locations, the server may return fs_locations only. This is to
be expected since the server has migrated the filesystem and may
not have a method of obtaining additional attribute data."
While the above seems quite reasonable, it is seemingly
contradicted by the following text from section 14.2.7 the second
paragraph of the DESCRIPTION for GETATTR: "The server must return a
value for each attribute that the client requests if the attribute
is supported by the server. If the server does not support an
attribute or cannot approximate a useful value then it must not
return the attribute value and must not set the attribute bit
Noveck Expires January 2005 [Page 5]
Internet-Draft Migration Issues for NFSv4 July 2004
in the result bitmap. The server must return an error if it
supports an attribute but cannot obtain its value. In that case no
attribute values will be returned."
While the above is a useful restriction in that it allows clients
to simplify their attribute interpretation code since it allows
them to assume that all of the attributes they request are present
often making it possible to get successive attributes at fixed
offsets within the data stream, it seems to contradict what is said
in section 6.2, where it is clearly anticipated, at least when
fs_locations is requested, that fewer (often many fewer) attributes
will be available than are requested. It could be argued that you
could harmonize these two by being creative with the interpretation
of the phrase "if the attribute is supported by the server". One
could argue that many attributes are not supported by the server
for an absent fs even though the text by talking about attributes
"supported by a server" seems to indicate that this is not allowed
to be different for different fs's (which is troublesome in itself
as one server might have filesystems that do support and don't
support acl's for example).
Note however that the following paragraph in the description says,
"All servers must support the mandatory attributes as specified in
the section 'File Attributes'". That's reasonable enough in
general, but for an absent fs it is not reasonable and so section
14.2.7 and section 6.2 are contradictory. Any new NFSv4 RFC should
remove the contradiction, while allowing servers to use the
approach outlined in section 6.2. It should also make sure that it
is clear that the server may choose to return other requested
attributes (e.g. fsid and mounted_on_fileid) rather than
fs_locations alone.
A related issue concerns attributes in a READDIR. RFC 3530 already
allows partial attribute return when rdattr_error is requested but
indicates that if it is not requested, errors must be returned if
not all requested attributes can be obtained. When READDIR is done
on a directory which contains mountpoints for absent fs's (either
those that were once present and then migrated or simple
referrals), this would seem to indicate that NFS4ERR_MOVED must be
returned if the directory is in absent filesystem or any of the
directory entries is the root of absent fs. This seems unduly
restrictive, but if that is the correct interpretation, it should
be made clear that the exception indicated in section 6.2 does not
apply in the READIR case, to avoid possible confusion.
Noveck Expires January 2005 [Page 6]
Internet-Draft Migration Issues for NFSv4 July 2004
5. Referral Issues
RFC 3530 defines a migration feature which allows the server to
direct clients to another server for the purpose of accessing a
given file system. While that document explains the feature in
terms of a client accessing a given file system and then finding
that it has moved, an important limiting case is that in which the
clients are redirected as part of their first attempt to access a
given file system.
Such redirection is often described as a referral event and
implementing such a form of migration has many important
consequences, which are not well explained by the presentation
within RFC 3530, which often assumes that the client is informed of
the migration event after one or more accesses within the file
system for which a migration event occurs.
5.1. Referral Situations
When a particular client is directed to a new location upon first
referencing a file system, the result is best seen, from the
client's point of view as a referral, rather than a migration
event, since the client contains no information derived from the
file system before the migration occurred.
Note that the above only refers to a particular client's point of
view. A given file system may be accessed by some clients and
thus, when a migration occurs, those clients will see an ordinary
migration event while other clients see a referral when they first
attempt to access the subject filesystem.
In the case in which none of the clients has referenced the subject
file system at the time of migration, we have a pure referral
situation, in that all that clients will ever see is the referral
for an absent file system. Given that clients can use such
referrals to find the current location of file systems, servers can
usefully provide such referrals when the filesystem in question
never actually resided on the server. Such referrals may allow
implementation of some forms of multi-server namespace, although
NFSv4 support of a global namespace would require considerable
additional work. Nevertheless, an arrangement where the client
addresses file systems in terms of the name of the filesystem on a
server providing referrals may be valuable, because it allows the
clients to isolate themselves from server configuration changes
which move file systems from server to server.
Noveck Expires January 2005 [Page 7]
Internet-Draft Migration Issues for NFSv4 July 2004
5.2. Referral Interactions (LOOKUP)
The details of how referrals proceed are implicit in the
specification of migration in RFC 3530. However, because the
details of handling of this case are so different from those in the
cases discussed therein, examples tailored to the referral
situation are needed to clarify matters and allow correct and
consistent implementations.
Let us suppose that the following COMPOUND is issued in an
environment in which /src/linux/2.7/latest is absent from the
target server. This may be for a number of reasons. It may be the
case that the file system has moved, or, it may be the case that
the target server is functioning mainly or solely to refer clients
to the server on which the file system is located.
o PUTROOTFH
o LOOKUP "src"
o LOOKUP "linux"
o LOOKUP "2.7"
o LOOKUP "latest"
o GETFH
o GETATTR fsid,fileid,size,ctime
Under the given circumstances, the following will be the result.
o PUTROOTFH --> NFS_OK
Current fh is root of pseudo-fs.
o LOOKUP "src" --> NFS_OK
Current fh is for /src and is within pseudo-fs.
o LOOKUP "linux" --> NFS_OK
Current fh is for /src/linux and is within pseudo-fs.
o LOOKUP "2.7" --> NFS_OK
Current fh is for /src/linux/2.7 and is within pseudo-fs.
Noveck Expires January 2005 [Page 8]
Internet-Draft Migration Issues for NFSv4 July 2004
o LOOKUP "latest" --> NFS_OK
Current fh is for /src/linux/2.7/latest and is within a new,
absent fs, but ...
The client will never see the value of that fh.
o GETFH --> NFS4ERR_MOVED
Fails because current fh is in an absent fs at the start of
the operation and the spec makes no exception for GETFH.
o GETATTR fsid,fileid,size,ctime
Not executed because the failure of the GETFH stops processing
of the COMPOUND.
Given the failure of the GETFH, the client has the job of
determining the root of the absent file system and where to find
that file system, i.e. the server and path relative to that
server's root fh. Note here that in this example, the client did
not obtain filehandles and attribute information (e.g. fsid) for
the intermediate directories, so that he would not be sure where
the absent file system starts. It could be the case, for example,
that /src/linux/2.7 is the root of the moved filesystem and that
the reason that the lookup of "latest" succeeded is that the
filesystem was not absent on that op but was moved between the last
LOOKUP and the GETFH (since COMPOUND is not atomic). Even if we
had the fsid's for all of the intermediate directories, we could
have no way of knowing that /src/linux/2.7/latest was the root of a
new fs, since we don't yet have its fsid.
In order to get the necessary information, let us re-issue the
chain of lookup's with GETFH's and GETATTR's to at least get fsid's
and fs_locations values.
o PUTROOTFH --> NFS_OK
Current fh is root of pseudo-fs.
o GETATTR(fsid) --> NFS_OK
Just for completeness. Normally, clients will know the fsid
of the pseudo-fs as soon as they establish communication with
a server.
o LOOKUP "src" --> NFS_OK
Noveck Expires January 2005 [Page 9]
Internet-Draft Migration Issues for NFSv4 July 2004
o GETATTR(fsid, fs_locations) --> NFS_OK
Get current fsid to see where fs boundaries are. The fsid
will be that for the pseudo-fs in this example, so no
boundary. Get fs_locations just in case "src" is part of fs
that moved.
o GETFH --> NFS_OK
Current fh is for /src and is within pseudo-fs.
o LOOKUP "linux" --> NFS_OK
Current fh is for /src/linux and is within pseudo-fs.
o GETATTR(fsid, fs_locations) --> NFS_OK
Get current fsid to see where fs boundaries are. The fsid
will be that for the pseudo-fs in this example, so no
boundary. Get fs_locations just in case "linux" is part of
the fs that moved.
o GETFH --> NFS_OK
Current fh is for /src/linux and is within pseudo-fs.
o LOOKUP "2.7" --> NFS_OK
Current fh is for /src/linux/2.7 and is within pseudo-fs.
o GETATTR(fsid, fs_locations) --> NFS_OK
Get current fsid to see where fs boundaries are. The fsid
will be that for the pseudo-fs in this example, so no
boundary. Get fs_locations just in case "2.7" is part of fs
that moved.
o GETFH --> NFS_OK
Current fh is for /src/linux/2.7 and is within pseudo-fs.
o LOOKUP "latest" --> NFS_OK
Current fh is for /src/linux/2.7/latest and is within a new,
absent fs, but ...
The client will never see the value of that fh
Noveck Expires January 2005 [Page 10]
Internet-Draft Migration Issues for NFSv4 July 2004
o GETATTR(fsid, fs_locations) --> NFS_OK
We are getting the fsid to know where the fs boundaries are.
The server may oblige us by giving us an fsid value different
from that of the pseudo-fs. However, RFC 3530 does not oblige
him to give us anything but fs_locations, so this may not be
available. Note that if we did have the fsid, it would not
necessarily be preserved at the new location. That fsid might
be different and in fact the fsid we have for this fs might be
the fsid of a different fs on that new server.
In this particular case, we are pretty sure anyway that what
has moved is /src/linux/2.7/latest rather than /src/linux/2.7
since we have the fsid of the latter and it is that of the
pseudo-fs, which presumably cannot move. However, in other
examples, we might not have this kind of information to rely
on (e.g. /src/linux/2.7 might be a non-pseudo filesystem
separate from /src/linux/2.7/latest), so we need to have
another reliable source information on the boundary of the fs
which is moved.
The fs_locations attribute indicates the server and server-
relative path of the fs's new location but it also gives us
the necessary information about the fs boundaries via the
fs_root field. In this case the fs_root field is
/src/lnux/2.7/latest, telling us where the moved fs starts.
o GETFH --> NFS4ERR_MOVED
Fails because current fh is in an absent fs at the start of
the operation and the spec makes no exception for GETFH. Note
that this has the happy consequence that we don't have to
worry about the volatility or lack thereof of the fh. If the
root of the fs on the new location is a persistent fh, then we
can assume that this fh, which we never saw is a persistent
fh, which, if we could see it, would exactly match the new fh.
At least, there is no evidence to disprove that. On the other
hand, if we find a volatile root at the new location, then the
filehandle which we never saw must have been volatile or at
least nobody can prove otherwise.
Given the above, the client knows where the root of the absent file
system is, either by noting where the change of fsid occurred, or,
if that is not provided, by means of the fs_root field of the
fs_locations attribute. The fs_locations attribute also gives the
client the actual location of the absent file system, so that the
referral can proceed. Generally, the server will give the client
the bare minimum of information about the absent file system so
Noveck Expires January 2005 [Page 11]
Internet-Draft Migration Issues for NFSv4 July 2004
that there will be very little scope for problems of conflict
between information sent by the referring server and information of
the file system's home. No filehandles and very few attributes are
present on the referring server and the client can treat those it
receives as basically transient information with the function of
enabling the referral.
5.3. Referral Interactions (READDIR)
Another context in which a client may encounter referrals is when
it does a READDIR on directory in which some of the sub-directories
are the roots of absent file systems. In this case, NFS4ERR_MOVED
is not an appropriate return because the directory in question is
available and only the entries, whose attributes are being
interrogated, are for absent file systems.
The appropriate approach for the server in this case is to provide
the attributes which it can provide and not provide those that
require access to the actual file system, while allowing the client
to deduce that an fs boundary is present and that the file system
is absent. Fortunately, this can be done fairly easily, as long as
the client and server take proper care.
The basic strategy is to return only the attributes that can
validly be provided by the referring server. Others are simply not
provided. The spec allows this to be done if the client requests
the rdattr_error as part of the READDIR, so, if the client does not
request this attribute routinely, it must do so when re-issuing a
READDIR which gets an NFS4ERR_MOVED error. Without a request for
rdattr_error, NFS4ERR_MOVED could mean that the directory being
read is within an absent file system or that one or more of the
entries in the directory is the root of an absent file system.
There is simply no way of determining which unless rdattr_error is
requested.
Assuming the rdattr_error is requested, the server should, for the
roots of absent file systems, return the attributes listed below
when they are requested and no others. Returning other attributes
may be possible in particular cases, but generally speaking, they
are not necessary for clients to function and since clients will
have to be prepared to get the necessary information from the
actual root of the fs on the other server, servers are best advised
to simply return this small set.
o fs_locations
Location of the file system for the client's use when he needs
to do the nested mount or to get attribute information about
Noveck Expires January 2005 [Page 12]
Internet-Draft Migration Issues for NFSv4 July 2004
the root of the fs.
o fsid
Needs to be a value different from the fsid of the containing
directory, in order to indicate to the client that a file
system boundary is present.
Note that the client should not expect that the actual fs,
when located, will have the same fsid. Fsid's are unique only
within the set of file systems exported by a single server so
it might be possible to maintain the fsid on a different
server. In any case, a client will be capable of using file
systems on multiple servers and will therefore, if it needs to
present unique identifiers for file systems to present to
applications, needs to create them and not assume that using
fsid's will provide the requisite uniqueness. So a change of
mapping from one fsid-server pair to a given id, to another
fsid-server pair as part of a referral or migration should not
pose difficulties.
o mounted_on_fileid
The mounted_on_fileid attribute is of particular importance to
many clients, in that they need this information to form a
proper response to a readdir() call. When a readdir() call is
done within UNIX, the d_ino field of each of the entries needs
to have a unique value normally derived from the NFSv4 fileid
attribute. It is in the case in which a file system boundary
is crossed that using the fileid attribute, particularly when
crossing into an absent fs, that use of the fileid attribute
for this purpose will pose problems. Note first that the
fileid attribute, since it is within a new fs and thus a new
fileid space, will not be unique within the directory. Also,
since the fs, at its new location, may arrange things
differently, the fileid decided on at the directing server may
be overridden at the target server, making it of little value.
Neither of these problems arise in the case of
mounted_on_fileid since that fileid is in the context of the
mounted-on fs and unique within it.
o rdattr_error
The value should always be NFS4ERR_MOVED for entries that
correspond to the root of absent file systems
Noveck Expires January 2005 [Page 13]
Internet-Draft Migration Issues for NFSv4 July 2004
5.4. Editorial Changes Related to Referrals
Given the above framework for implementing referrals, within the
basic migration framework described in RFC 3530, we need to
consider how future NFSv4 RFC's should be modified, relative to RFC
3530, to address referrals.
The most important change is to include an explanation of how
referrals fit into the v4 migration model. Since the existing
discussion does not specifically call out the case in which the
absence of a filesystem is noted while attempting to cross into the
absent file system, it makes it hard to understand how referrals
would work within the existing protocol. This needs to be
corrected to allow better understanding of the capabilities of
NFSv4.0 which will be retained in future minor versions of NFSv4.
It makes sense to present a description of referrals in a new sub-
section following the "Migration" section, and would be section
6.2.1, given the current numbering scheme of RFC 3530. The
material in the previous sub-sections of this document should be
helpful in explaining the details of referral handling.
There are also a number of cases in which the existing wording of
RFC 3530 seems to ignore the referral case of the migration
feature. In the following specific cases, some suggestions are
made for edits to tidy this up.
o In section 1.4.3.3, in the third sentence of the first
paragraph, the phrase "In the event of a migration of a
filesystem" is unnecessarily restrictive and having the
sentence read "In the event of the absence of a filesystem,
the client will receive an error when operating on the
filesystem and it can then query the server as to the current
location of the file system" would be better.
o In section 6.2, the following should be added as a new second
paragraph: "Migration may be signaled when a file system is
absent on a given server, when the file system in question has
never actually been located on the server in question. In
such a case, the server acts to refer the client to the proper
fs location, using fs_locations to indicate the server
location, with the existence of the server as a migration
source being purely conventional."
o In the existing second paragraph of section 6.2, the first
sentence should be modified to read as follows: "Once a
filesystem has been successfully established at a new server
location, the error NFS4ERR_MOVED will be returned for
subsequent requests received by the server whose role is as
Noveck Expires January 2005 [Page 14]
Internet-Draft Migration Issues for NFSv4 July 2004
the source of the filesystem, whether the filesystem actually
resided on that server, or whether its original location was
purely nominal (i.e. the pure referral case)."
o The following should be added as an additional paragraph to
the end of section 6.4, the: "Note that in the case of a
referral, there is no issue of filehandle recovery since no
filehandles for the absent filesystem are communicated to the
client (and neither is the fh_expire_type)".
o The following should be added as an additional paragraph to
the end of section 8.14.1: "Note that in the case of referral,
there is no issue of state recovery since no state can have
been generated for the absent filesystem."
o In section 12, in the description of NFS4ERR_MOVED, the first
sentence should read, "The filesystem which contains the
current filehandle object is now located on another server."
6. Acknowledgements
The author wishes to thank Neil Brown for his helpful comments.
7. Normative References
[RFC3530]
S. Shepler, et. al., "NFS Version 4 Protocol", Standards Track
RFC
Author's Address
David Noveck
Network Appliance, Inc.
375 Totten Pond Road
Waltham, MA 02451 USA
Phone: +1 781 768 5347
EMail: dnoveck@netapp.com
Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is
subject to the rights, licenses and restrictions contained in BCP
78 and except as set forth therein, the authors retain all their
rights.
This document and the information contained herein are provided on
Noveck Expires January 2005 [Page 15]
Internet-Draft Migration Issues for NFSv4 July 2004
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Noveck Expires January 2005 [Page 16]