I'm sponsoring this case for Bill Baker of the NFS team. This
case proposed enabling technology for a forthcoming closed case.
The timer expires on Friday, September 4, 2009.
This case requests minor binding.
Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
This information is Copyright 2009 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
nfs4_fid()
1.2. Name of Document Author/Supplier:
Author: Bill Baker
1.3 Date of This Document:
28 August, 2009
4. Technical Description
Historically, the NFSv4 client has not implemented the VOP_FID()
function due to fundamental limitations of the protocol. The client
cannot construct a file identifier which can be used to reactivate a
vnode (via VFS_VGET()) which is usable in all cases. In particular,
volatile file handle recovery as well as handling VOP_OPEN() is
impossible without the additional information which is created and
maintained by the NFSv4 client during VOP_LOOKUP(). Vnodes activated
via VFS_VGET() may not have this information, nor can it be
constructed. Given these limitations, the current nfs4_fid() simply
returns EREMOTE.
However, having nfs4_fid() return a file id can be useful in a very
narrow, controlled context. This file ID can be used as an opaque
cookie which can be compared to file IDs from other vnodes from the
same vfs. This could be used by a file tree walking program to
determine if a newly looked up file had been discovered previously
since, by definition, the file handle uniquely identifies a different
file in the protocol. This ID is persistent (assuming the server is
using persistent file handles) and is therefore durable and reliable
across reboots of both the client and server. The consumer of this ID
can write it to stable storage and safely recover its state even after
a client reboot.
Therefore, nfs4_fid() is reimplemented to return the client file handle
from the rnode as a file ID, solely for the purpose of doing this
equivalency comparison. nfs4_vget() will not honor this file ID,
meaning that it can ONLY be used in this manner, it cannot be used to
activate a vnode.
Since this new behavior may expose existing subsystems, like cachefs,
to new failure modes, nfs4_fid() will only return a file ID when the
client file system is mounted with "-o fid". By default, the option is
off and the NFSv4 client will retain its current behavior.
Ideally, this mount option is only used by system components which wish
to use the file ID for identification as described above. Other uses
are not supported. The option will NOT be documented, due to its
limited utility.
|Proposed |Specified |
|Stability |in what |
Interface Name |Classification |Document? | Comments
===============================================================================
|Consolidation |This |
-o fid |Private |Document | new option to
| | | mount_nfs
| | |
6. Resources and Schedule
6.4. Steering Committee requested information
6.4.1. Consolidation C-team Name:
ON
6.5. ARC review type: FastTrack
6.6. ARC Exposure: open
