idnits 2.17.1 draft-noveck-nfsv4-migration-issues-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 703. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 714. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 721. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 727. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 694), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 309 has weird spacing: '...orms of multi...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2004) is 7224 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3530' is defined on line 675, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3530 (Obsoleted by RFC 7530) Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT David Noveck 3 Expires: January 2005 Network Appliance, Inc. 5 July 2004 7 Migration Issues for NFSv4 8 draft-noveck-nfsv4-migration-issues-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 or will be disclosed, and any of which I become aware will be 15 disclosed, in accordance with RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet-Drafts 25 as reference material or to cite them other than as "work in 26 progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt The list of 30 Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 RFC3530 described an fs_locations attribute which can be used to 40 allow an fs to migrate between servers without disrupting client 41 access and to refer a client to another server providing access to 42 a specified file system. Initial implementation work for this 43 feature has exposed a number of areas where RFC3530's handling of 44 the issues leaves something to be desired. This document makes a 45 number of suggestions to remedy these issues when the NFSv4 spec 46 next undergoes a significant revision, most likely in connection 47 with implementing a new minor revision, such as NFSv4.1. 49 Table Of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Attributes Returned by GETATTR and READDIR . . . . . . . . 2 53 3. Discussion of Error Codes . . . . . . . . . . . . . . . . 4 54 4. Issues of Incomplete Attribute Sets . . . . . . . . . . . 5 55 5. Referral Issues . . . . . . . . . . . . . . . . . . . . . 6 56 Acknowledgements . . . . . . . . . . . . . . . . . . . . . 15 57 Normative References . . . . . . . . . . . . . . . . . . . 15 58 Author's Address . . . . . . . . . . . . . . . . . . . . . 15 59 Full Copyright Statement . . . . . . . . . . . . . . . . . 15 61 1. Introduction 63 Ongoing design work has exposed a number of weaknesses in the 64 discussion of migration within RFC 3530. While there does not 65 appear any necessity to change any message formats or add 66 operations, a number of migration-related issues should be 67 addressed when the protocol is updated for v4.1. The purpose of 68 this document is to clearly lay out what needs to be done, so that 69 any possible updates can be discussed as part of the process of 70 formulating a spec for v4.1. Some of the items discussed below 71 might also be appropriate in the context of an update of the NFSv4 72 spec in connection with going to a Draft Standard status. 74 2. Attributes Returned by GETATTR and READDIR 76 While the RFC3530 allows the server to return attributes in 77 addition to fs_locations, when GETATTR is used with a current 78 filehandle within an absent filesystem, not much guidance is given 79 to help clarify what is appropriate. In particular, there are a 80 number of attributes which most server implementations should find 81 relatively easy to supply which would be of value to clients, 82 particularly in those cases in which NFS4ERR_MOVED is returned when 83 first crossing into an absent file system that the client has not 84 referenced. 86 The NFSv4 spec should encourage servers to return the attributes 87 fsid and mounted_on_fileid for absent file systems. The specific 88 reasons will be discussed below. 90 On the other hand, a number of attributes pose difficulties when 91 returned for an absent filesystem. While not prohibiting the 92 server from returning these, the NFSv4 spec should explain the 93 issues which may result in problems, since these are not always 94 obvious. Handling of specific attributes is discussed below. 96 2.1. fsid 98 The fsid attribute allows clients to recognize when fs boundaries 99 have been crossed. This applies also when one crosses into an 100 absent filesystem. While returning fsid is not absolutely 101 required, since fs boundaries are also reflected, in this case, by 102 means of the fs_root field of the fs_locations attribute, returning 103 fsid is helpful and servers should have no difficulty in providing 104 it. 106 To avoid misunderstanding, any new NFSv4 RPC should note that the 107 fsid provided in this case is solely so that the fs boundaries can 108 be properly noted and that the fsid returned will not necessarily 109 be valid after resolution of the migration event. The logic of 110 fsid handling for NFSv4 is that fsid's are only unique within a 111 per-server context. This would seem to be a strong indication that 112 they need not be persistent when file systems are moved from server 113 to server, although RFC 3530 does not specifically address the 114 matter. 116 2.2. mounted_on_fileid 118 The mounted_on_fileid attribute is of particular importance to many 119 clients, in that they need this information to form a proper 120 response to a readdir() call. When a readdir() call is done within 121 UNIX, the d_ino field of each of the entries needs to have a unique 122 value normally derived from the NFSv4 fileid attribute. It is in 123 the case in which a file system boundary is crossed that using the 124 fileid attribute for this purpose, particularly when crossing into 125 an absent fs, will pose problems. Note first that the fileid 126 attribute, since it is within a new fs and thus a new fileid space, 127 will not be unique within the directory. Also, since the fs, at 128 its new location, may arrange things differently, the fileid 129 decided on at the directing server may be overridden at the target 130 server, making it of little value. Neither of these problems arise 131 in the case of mounted_on_fileid since that fileid is in the 132 context of the mounted-on fs and unique within it. 134 2.3. fileid 136 For reasons explained above under mounted_on_fileid, it would be 137 difficult for the referring server to provide a fileid value that 138 is of any use to the client. Given this, it seems much better for 139 the server never to return fileid values for files on an absent fs. 141 2.4. filehandle 143 Returning file handles for files in the absent fs, whether by use 144 of GETFH (discussed below) or by using the filehandle attribute 145 with GETATTR or READDIR poses problems for the client as the server 146 to which it is referred is likely not to assign the same filehandle 147 value to the object in question. Even though it is possible that 148 volatile filehandles may allow a change, the referring server 149 should not prejudge the issue of filehandle volatility for the 150 server which actually has the fs. By not providing the file 151 handle, the referring server allows the target server freedom to 152 choose the file handle value without constraint. 154 3. Discussion of Error Codes 156 There are a number of cases in which RFC 3530 is either unclear or 157 simply incorrect about the situations in which NFS4ERR_MOVED is to 158 be returned. Discussion of these issues has exposed the following 159 problems, which should be addressed to provide greater clarity and 160 correctness: 162 3.1. Issue of when to check current filehandle 164 In providing the definition of NFS4ERR_MOVED, RFC 3530 refers to 165 the "filesystem which contains the current filehandle object" being 166 moved to another server. This has led to some confusion when 167 considering the case of operations which change the current 168 filehandle and potentially the current file system. For example, a 169 LOOKUP which causes a transition to an absent file system might be 170 supposed to result in this error. This should be clarified to make 171 it explicit that only the current filehandle at the start of the 172 operation can result in NFS4ERR_MOVED. 174 3.2. Issue of GETFH 176 While RFC 3530 does not make any exception for GETFH when the 177 current filehandle is within an absent filesystem, the fact that 178 GETFH is such a passive, purely interrogative operation, may lead 179 readers to wrongly suppose that an NFSERR_MOVED error will not 180 arise in this situation. Any new NFSv4 RFC should explicitly state 181 that GETFH will return this error if the current filehandle is 182 within an absent filesystem. 184 3.3. Inconsistent handling of PUTFH 186 While RFC 3530 states (in section 6.2) "The NFS4ERR_MOVED error is 187 returned for all operations except PUTFH and GETATTR." Despite 188 this, RFC 3530 lists NFS4ERR_MOVED as an error that can be returned 189 by PUTFH. Any new NFSv4 RFC should delete this as a possible error 190 for PUTFH. 192 3.4. Inconsistent handling of GETATTR 194 While, as noted above, RFC 3530 indicates that NFS4ERR_MOVED is not 195 returned for a GETATTR operation, NFS4ERR_MOVED is listed as an 196 error that can be returned by GETATTR. It seems reasonable to 197 allow NFS4ERR_MOVED to be returned by GETATTR's that do not 198 interrogate the fs_locations attribute while maintaining the 199 exception which allows GETATTR to be used to get fs_locations 200 information by establishing the rules that GETATTR's which 201 interrogate fs_locations (with or without additional attributes) 202 will not return NFS4ERR_MOVED. 204 4. Issues of Incomplete Attribute Sets 206 Migration or referral events naturally create situations in which 207 all of the attributes normally supported on a server are not 208 obtainable. RFC3530 is in places ambivalent and/or apparently 209 self-contradictory on such issues. Any new NFSv4 RFC should take a 210 clear position on these issues (and it should not impose undue 211 difficulties on support for migration). 213 The first problem concerns the statement in the third paragraph of 214 section 6.2: "If the client requests more attributes than just 215 fs_locations, the server may return fs_locations only. This is to 216 be expected since the server has migrated the filesystem and may 217 not have a method of obtaining additional attribute data." 219 While the above seems quite reasonable, it is seemingly 220 contradicted by the following text from section 14.2.7 the second 221 paragraph of the DESCRIPTION for GETATTR: "The server must return a 222 value for each attribute that the client requests if the attribute 223 is supported by the server. If the server does not support an 224 attribute or cannot approximate a useful value then it must not 225 return the attribute value and must not set the attribute bit 226 in the result bitmap. The server must return an error if it 227 supports an attribute but cannot obtain its value. In that case no 228 attribute values will be returned." 230 While the above is a useful restriction in that it allows clients 231 to simplify their attribute interpretation code since it allows 232 them to assume that all of the attributes they request are present 233 often making it possible to get successive attributes at fixed 234 offsets within the data stream, it seems to contradict what is said 235 in section 6.2, where it is clearly anticipated, at least when 236 fs_locations is requested, that fewer (often many fewer) attributes 237 will be available than are requested. It could be argued that you 238 could harmonize these two by being creative with the interpretation 239 of the phrase "if the attribute is supported by the server". One 240 could argue that many attributes are not supported by the server 241 for an absent fs even though the text by talking about attributes 242 "supported by a server" seems to indicate that this is not allowed 243 to be different for different fs's (which is troublesome in itself 244 as one server might have filesystems that do support and don't 245 support acl's for example). 247 Note however that the following paragraph in the description says, 248 "All servers must support the mandatory attributes as specified in 249 the section 'File Attributes'". That's reasonable enough in 250 general, but for an absent fs it is not reasonable and so section 251 14.2.7 and section 6.2 are contradictory. Any new NFSv4 RFC should 252 remove the contradiction, while allowing servers to use the 253 approach outlined in section 6.2. It should also make sure that it 254 is clear that the server may choose to return other requested 255 attributes (e.g. fsid and mounted_on_fileid) rather than 256 fs_locations alone. 258 A related issue concerns attributes in a READDIR. RFC 3530 already 259 allows partial attribute return when rdattr_error is requested but 260 indicates that if it is not requested, errors must be returned if 261 not all requested attributes can be obtained. When READDIR is done 262 on a directory which contains mountpoints for absent fs's (either 263 those that were once present and then migrated or simple 264 referrals), this would seem to indicate that NFS4ERR_MOVED must be 265 returned if the directory is in absent filesystem or any of the 266 directory entries is the root of absent fs. This seems unduly 267 restrictive, but if that is the correct interpretation, it should 268 be made clear that the exception indicated in section 6.2 does not 269 apply in the READIR case, to avoid possible confusion. 271 5. Referral Issues 273 RFC 3530 defines a migration feature which allows the server to 274 direct clients to another server for the purpose of accessing a 275 given file system. While that document explains the feature in 276 terms of a client accessing a given file system and then finding 277 that it has moved, an important limiting case is that in which the 278 clients are redirected as part of their first attempt to access a 279 given file system. 281 Such redirection is often described as a referral event and 282 implementing such a form of migration has many important 283 consequences, which are not well explained by the presentation 284 within RFC 3530, which often assumes that the client is informed of 285 the migration event after one or more accesses within the file 286 system for which a migration event occurs. 288 5.1. Referral Situations 290 When a particular client is directed to a new location upon first 291 referencing a file system, the result is best seen, from the 292 client's point of view as a referral, rather than a migration 293 event, since the client contains no information derived from the 294 file system before the migration occurred. 296 Note that the above only refers to a particular client's point of 297 view. A given file system may be accessed by some clients and 298 thus, when a migration occurs, those clients will see an ordinary 299 migration event while other clients see a referral when they first 300 attempt to access the subject filesystem. 302 In the case in which none of the clients has referenced the subject 303 file system at the time of migration, we have a pure referral 304 situation, in that all that clients will ever see is the referral 305 for an absent file system. Given that clients can use such 306 referrals to find the current location of file systems, servers can 307 usefully provide such referrals when the filesystem in question 308 never actually resided on the server. Such referrals may allow 309 implementation of some forms of multi-server namespace, although 310 NFSv4 support of a global namespace would require considerable 311 additional work. Nevertheless, an arrangement where the client 312 addresses file systems in terms of the name of the filesystem on a 313 server providing referrals may be valuable, because it allows the 314 clients to isolate themselves from server configuration changes 315 which move file systems from server to server. 317 5.2. Referral Interactions (LOOKUP) 319 The details of how referrals proceed are implicit in the 320 specification of migration in RFC 3530. However, because the 321 details of handling of this case are so different from those in the 322 cases discussed therein, examples tailored to the referral 323 situation are needed to clarify matters and allow correct and 324 consistent implementations. 326 Let us suppose that the following COMPOUND is issued in an 327 environment in which /src/linux/2.7/latest is absent from the 328 target server. This may be for a number of reasons. It may be the 329 case that the file system has moved, or, it may be the case that 330 the target server is functioning mainly or solely to refer clients 331 to the server on which the file system is located. 333 o PUTROOTFH 335 o LOOKUP "src" 337 o LOOKUP "linux" 339 o LOOKUP "2.7" 341 o LOOKUP "latest" 343 o GETFH 345 o GETATTR fsid,fileid,size,ctime 347 Under the given circumstances, the following will be the result. 349 o PUTROOTFH --> NFS_OK 351 Current fh is root of pseudo-fs. 353 o LOOKUP "src" --> NFS_OK 355 Current fh is for /src and is within pseudo-fs. 357 o LOOKUP "linux" --> NFS_OK 359 Current fh is for /src/linux and is within pseudo-fs. 361 o LOOKUP "2.7" --> NFS_OK 363 Current fh is for /src/linux/2.7 and is within pseudo-fs. 365 o LOOKUP "latest" --> NFS_OK 367 Current fh is for /src/linux/2.7/latest and is within a new, 368 absent fs, but ... 370 The client will never see the value of that fh. 372 o GETFH --> NFS4ERR_MOVED 374 Fails because current fh is in an absent fs at the start of 375 the operation and the spec makes no exception for GETFH. 377 o GETATTR fsid,fileid,size,ctime 379 Not executed because the failure of the GETFH stops processing 380 of the COMPOUND. 382 Given the failure of the GETFH, the client has the job of 383 determining the root of the absent file system and where to find 384 that file system, i.e. the server and path relative to that 385 server's root fh. Note here that in this example, the client did 386 not obtain filehandles and attribute information (e.g. fsid) for 387 the intermediate directories, so that he would not be sure where 388 the absent file system starts. It could be the case, for example, 389 that /src/linux/2.7 is the root of the moved filesystem and that 390 the reason that the lookup of "latest" succeeded is that the 391 filesystem was not absent on that op but was moved between the last 392 LOOKUP and the GETFH (since COMPOUND is not atomic). Even if we 393 had the fsid's for all of the intermediate directories, we could 394 have no way of knowing that /src/linux/2.7/latest was the root of a 395 new fs, since we don't yet have its fsid. 397 In order to get the necessary information, let us re-issue the 398 chain of lookup's with GETFH's and GETATTR's to at least get fsid's 399 and fs_locations values. 401 o PUTROOTFH --> NFS_OK 403 Current fh is root of pseudo-fs. 405 o GETATTR(fsid) --> NFS_OK 407 Just for completeness. Normally, clients will know the fsid 408 of the pseudo-fs as soon as they establish communication with 409 a server. 411 o LOOKUP "src" --> NFS_OK 412 o GETATTR(fsid, fs_locations) --> NFS_OK 414 Get current fsid to see where fs boundaries are. The fsid 415 will be that for the pseudo-fs in this example, so no 416 boundary. Get fs_locations just in case "src" is part of fs 417 that moved. 419 o GETFH --> NFS_OK 421 Current fh is for /src and is within pseudo-fs. 423 o LOOKUP "linux" --> NFS_OK 425 Current fh is for /src/linux and is within pseudo-fs. 427 o GETATTR(fsid, fs_locations) --> NFS_OK 429 Get current fsid to see where fs boundaries are. The fsid 430 will be that for the pseudo-fs in this example, so no 431 boundary. Get fs_locations just in case "linux" is part of 432 the fs that moved. 434 o GETFH --> NFS_OK 436 Current fh is for /src/linux and is within pseudo-fs. 438 o LOOKUP "2.7" --> NFS_OK 440 Current fh is for /src/linux/2.7 and is within pseudo-fs. 442 o GETATTR(fsid, fs_locations) --> NFS_OK 444 Get current fsid to see where fs boundaries are. The fsid 445 will be that for the pseudo-fs in this example, so no 446 boundary. Get fs_locations just in case "2.7" is part of fs 447 that moved. 449 o GETFH --> NFS_OK 451 Current fh is for /src/linux/2.7 and is within pseudo-fs. 453 o LOOKUP "latest" --> NFS_OK 455 Current fh is for /src/linux/2.7/latest and is within a new, 456 absent fs, but ... 458 The client will never see the value of that fh 460 o GETATTR(fsid, fs_locations) --> NFS_OK 462 We are getting the fsid to know where the fs boundaries are. 463 The server may oblige us by giving us an fsid value different 464 from that of the pseudo-fs. However, RFC 3530 does not oblige 465 him to give us anything but fs_locations, so this may not be 466 available. Note that if we did have the fsid, it would not 467 necessarily be preserved at the new location. That fsid might 468 be different and in fact the fsid we have for this fs might be 469 the fsid of a different fs on that new server. 471 In this particular case, we are pretty sure anyway that what 472 has moved is /src/linux/2.7/latest rather than /src/linux/2.7 473 since we have the fsid of the latter and it is that of the 474 pseudo-fs, which presumably cannot move. However, in other 475 examples, we might not have this kind of information to rely 476 on (e.g. /src/linux/2.7 might be a non-pseudo filesystem 477 separate from /src/linux/2.7/latest), so we need to have 478 another reliable source information on the boundary of the fs 479 which is moved. 481 The fs_locations attribute indicates the server and server- 482 relative path of the fs's new location but it also gives us 483 the necessary information about the fs boundaries via the 484 fs_root field. In this case the fs_root field is 485 /src/lnux/2.7/latest, telling us where the moved fs starts. 487 o GETFH --> NFS4ERR_MOVED 489 Fails because current fh is in an absent fs at the start of 490 the operation and the spec makes no exception for GETFH. Note 491 that this has the happy consequence that we don't have to 492 worry about the volatility or lack thereof of the fh. If the 493 root of the fs on the new location is a persistent fh, then we 494 can assume that this fh, which we never saw is a persistent 495 fh, which, if we could see it, would exactly match the new fh. 496 At least, there is no evidence to disprove that. On the other 497 hand, if we find a volatile root at the new location, then the 498 filehandle which we never saw must have been volatile or at 499 least nobody can prove otherwise. 501 Given the above, the client knows where the root of the absent file 502 system is, either by noting where the change of fsid occurred, or, 503 if that is not provided, by means of the fs_root field of the 504 fs_locations attribute. The fs_locations attribute also gives the 505 client the actual location of the absent file system, so that the 506 referral can proceed. Generally, the server will give the client 507 the bare minimum of information about the absent file system so 508 that there will be very little scope for problems of conflict 509 between information sent by the referring server and information of 510 the file system's home. No filehandles and very few attributes are 511 present on the referring server and the client can treat those it 512 receives as basically transient information with the function of 513 enabling the referral. 515 5.3. Referral Interactions (READDIR) 517 Another context in which a client may encounter referrals is when 518 it does a READDIR on directory in which some of the sub-directories 519 are the roots of absent file systems. In this case, NFS4ERR_MOVED 520 is not an appropriate return because the directory in question is 521 available and only the entries, whose attributes are being 522 interrogated, are for absent file systems. 524 The appropriate approach for the server in this case is to provide 525 the attributes which it can provide and not provide those that 526 require access to the actual file system, while allowing the client 527 to deduce that an fs boundary is present and that the file system 528 is absent. Fortunately, this can be done fairly easily, as long as 529 the client and server take proper care. 531 The basic strategy is to return only the attributes that can 532 validly be provided by the referring server. Others are simply not 533 provided. The spec allows this to be done if the client requests 534 the rdattr_error as part of the READDIR, so, if the client does not 535 request this attribute routinely, it must do so when re-issuing a 536 READDIR which gets an NFS4ERR_MOVED error. Without a request for 537 rdattr_error, NFS4ERR_MOVED could mean that the directory being 538 read is within an absent file system or that one or more of the 539 entries in the directory is the root of an absent file system. 540 There is simply no way of determining which unless rdattr_error is 541 requested. 543 Assuming the rdattr_error is requested, the server should, for the 544 roots of absent file systems, return the attributes listed below 545 when they are requested and no others. Returning other attributes 546 may be possible in particular cases, but generally speaking, they 547 are not necessary for clients to function and since clients will 548 have to be prepared to get the necessary information from the 549 actual root of the fs on the other server, servers are best advised 550 to simply return this small set. 552 o fs_locations 554 Location of the file system for the client's use when he needs 555 to do the nested mount or to get attribute information about 556 the root of the fs. 558 o fsid 560 Needs to be a value different from the fsid of the containing 561 directory, in order to indicate to the client that a file 562 system boundary is present. 564 Note that the client should not expect that the actual fs, 565 when located, will have the same fsid. Fsid's are unique only 566 within the set of file systems exported by a single server so 567 it might be possible to maintain the fsid on a different 568 server. In any case, a client will be capable of using file 569 systems on multiple servers and will therefore, if it needs to 570 present unique identifiers for file systems to present to 571 applications, needs to create them and not assume that using 572 fsid's will provide the requisite uniqueness. So a change of 573 mapping from one fsid-server pair to a given id, to another 574 fsid-server pair as part of a referral or migration should not 575 pose difficulties. 577 o mounted_on_fileid 579 The mounted_on_fileid attribute is of particular importance to 580 many clients, in that they need this information to form a 581 proper response to a readdir() call. When a readdir() call is 582 done within UNIX, the d_ino field of each of the entries needs 583 to have a unique value normally derived from the NFSv4 fileid 584 attribute. It is in the case in which a file system boundary 585 is crossed that using the fileid attribute, particularly when 586 crossing into an absent fs, that use of the fileid attribute 587 for this purpose will pose problems. Note first that the 588 fileid attribute, since it is within a new fs and thus a new 589 fileid space, will not be unique within the directory. Also, 590 since the fs, at its new location, may arrange things 591 differently, the fileid decided on at the directing server may 592 be overridden at the target server, making it of little value. 593 Neither of these problems arise in the case of 594 mounted_on_fileid since that fileid is in the context of the 595 mounted-on fs and unique within it. 597 o rdattr_error 599 The value should always be NFS4ERR_MOVED for entries that 600 correspond to the root of absent file systems 602 5.4. Editorial Changes Related to Referrals 604 Given the above framework for implementing referrals, within the 605 basic migration framework described in RFC 3530, we need to 606 consider how future NFSv4 RFC's should be modified, relative to RFC 607 3530, to address referrals. 609 The most important change is to include an explanation of how 610 referrals fit into the v4 migration model. Since the existing 611 discussion does not specifically call out the case in which the 612 absence of a filesystem is noted while attempting to cross into the 613 absent file system, it makes it hard to understand how referrals 614 would work within the existing protocol. This needs to be 615 corrected to allow better understanding of the capabilities of 616 NFSv4.0 which will be retained in future minor versions of NFSv4. 617 It makes sense to present a description of referrals in a new sub- 618 section following the "Migration" section, and would be section 619 6.2.1, given the current numbering scheme of RFC 3530. The 620 material in the previous sub-sections of this document should be 621 helpful in explaining the details of referral handling. 623 There are also a number of cases in which the existing wording of 624 RFC 3530 seems to ignore the referral case of the migration 625 feature. In the following specific cases, some suggestions are 626 made for edits to tidy this up. 628 o In section 1.4.3.3, in the third sentence of the first 629 paragraph, the phrase "In the event of a migration of a 630 filesystem" is unnecessarily restrictive and having the 631 sentence read "In the event of the absence of a filesystem, 632 the client will receive an error when operating on the 633 filesystem and it can then query the server as to the current 634 location of the file system" would be better. 636 o In section 6.2, the following should be added as a new second 637 paragraph: "Migration may be signaled when a file system is 638 absent on a given server, when the file system in question has 639 never actually been located on the server in question. In 640 such a case, the server acts to refer the client to the proper 641 fs location, using fs_locations to indicate the server 642 location, with the existence of the server as a migration 643 source being purely conventional." 645 o In the existing second paragraph of section 6.2, the first 646 sentence should be modified to read as follows: "Once a 647 filesystem has been successfully established at a new server 648 location, the error NFS4ERR_MOVED will be returned for 649 subsequent requests received by the server whose role is as 650 the source of the filesystem, whether the filesystem actually 651 resided on that server, or whether its original location was 652 purely nominal (i.e. the pure referral case)." 654 o The following should be added as an additional paragraph to 655 the end of section 6.4, the: "Note that in the case of a 656 referral, there is no issue of filehandle recovery since no 657 filehandles for the absent filesystem are communicated to the 658 client (and neither is the fh_expire_type)". 660 o The following should be added as an additional paragraph to 661 the end of section 8.14.1: "Note that in the case of referral, 662 there is no issue of state recovery since no state can have 663 been generated for the absent filesystem." 665 o In section 12, in the description of NFS4ERR_MOVED, the first 666 sentence should read, "The filesystem which contains the 667 current filehandle object is now located on another server." 669 6. Acknowledgements 671 The author wishes to thank Neil Brown for his helpful comments. 673 7. Normative References 675 [RFC3530] 676 S. Shepler, et. al., "NFS Version 4 Protocol", Standards Track 677 RFC 679 Author's Address 681 David Noveck 682 Network Appliance, Inc. 683 375 Totten Pond Road 684 Waltham, MA 02451 USA 686 Phone: +1 781 768 5347 687 EMail: dnoveck@netapp.com 689 Full Copyright Statement 691 Copyright (C) The Internet Society (2004). This document is 692 subject to the rights, licenses and restrictions contained in BCP 693 78 and except as set forth therein, the authors retain all their 694 rights. 696 This document and the information contained herein are provided on 697 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 698 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 699 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 700 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 701 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 702 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 703 PARTICULAR PURPOSE. 705 Intellectual Property 707 The IETF takes no position regarding the validity or scope of any 708 Intellectual Property Rights or other rights that might be claimed 709 to pertain to the implementation or use of the technology described 710 in this document or the extent to which any license under such 711 rights might or might not be available; nor does it represent that 712 it has made any independent effort to identify any such rights. 713 Information on the procedures with respect to rights in RFC 714 documents can be found in BCP 78 and BCP 79. 716 Copies of IPR disclosures made to the IETF Secretariat and any 717 assurances of licenses to be made available, or the result of an 718 attempt made to obtain a general license or permission for the use 719 of such proprietary rights by implementers or users of this 720 specification can be obtained from the IETF on-line IPR repository 721 at http://www.ietf.org/ipr. 723 The IETF invites any interested party to bring to its attention any 724 copyrights, patents or patent applications, or other proprietary 725 rights that may cover technology that may be required to implement 726 this standard. Please address the information to the IETF at ietf- 727 ipr@ietf.org. 729 Acknowledgement 731 Funding for the RFC Editor function is currently provided by the 732 Internet Society.