Re: nfs exporting my stacked fs

[Andrew Sharp <andy@ccpu.com>]

On Sat, May 31, 2003 at 01:10:09AM +0200, Trond Myklebust wrote:
> >>>>> " " == Bryan Henderson <hbryan@us.ibm.com> writes:
> 
>      > This is true in any instant, but for most NFS purposes, we also
>      > care about identifying a file uniquely over time, even when
>      > that time might involve sea changes such as a reboot.  E.g. one
>      > would like to make sure that a file handle that referred to
>      > file A an hour ago still refers to file A now.
> 
> According to RFC1813 (which clarifies common practices for RFC1094)
> file handles are *unique*. More specifically:
> 
>   "If two file handles from the same server are equal, they must refer
>   to the same file, but if they are not equal, no conclusions can be
>   drawn."
> 
> RFC1813 makes no exceptions to this rule. Including for time....

Yes.  At first I was annoyed that the Linux NFS client peeks at the
file handle, because sometimes I want to change it for the same file,
but then it turns out that the solution to another problem of mine
fixes that as well.  And now it sounds like the v4 file handle won't
be considered opaque for the client any more.  As far as being able to
find the right file from a file handle, no matter how dusty, my fs has
the same problem as NFS in this regard.  A bit of challenge on Linux if
one hopes to maintain a proper dcache.

> The one thing that is allowed, is that the server may revoke a
> filehandle if (and only if) the file no longer exists, or if access to
> the file has been revoked.
> 
> 
> IOW: the condition you describe above is trivially observed...

I take it then that the fsid returned by ->statfs is largely not used
right now?  My version of nfs-utils (1.0) doesn't support the fsid option
in config files, so I've just hacked the kernel to get me through this
part of the development phase.

I'm guessing that all or part of this stuff is handled a bit differently
in 2.5?

a