On Fri, Aug 28, 2009 at 04:07:03PM -0500, Rich.Brown at Sun.COM wrote: > 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
That's a big assumption. There was a thread recently on nfs-discuss about adding server support for volatile file handles, for use with FUSE filesystems that lack persistent file IDs. I think that would be very useful. But even beyond that, volatile filehandles are in there to help cope with filesystems such as FAT, where no persistent file IDs exist, and so existing servers may very well be using volatile filehandles. > 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. Doesn't sound right to me. But then, this: > 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. limits the damage that one could do by persistently storing volatile FIDs. > 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. It might be better if there was a way for the VOP to indicate that the returned FID is volatile. Maybe a pathconf that looks at the per-filesystem fh_expire_type attribute? Nico --
