NFS on NFS?

[Eric Anderson]

Rick Macklem wrote:
> 
> 
> On Tue, 17 Jul 2007, Eric Anderson wrote:
> 
>> Here's what I'd like to do:
>>
>> - Mount NFS export from filer 'A'
>> - Export that mountpoint to clients via NFS
>>
>> I've already tried it, and it doesn't quite work.  FreeBSD allows me 
>> to export it (doing tricks like null mounting the NFS mounted 
>> directory on a different directory, etc).  But when a client mounts 
>> it, it has issues.
>>
>> Does anyone know if this is a reasonable problem to solve for FreeBSD, 
>> or is it so much work that it isn't worth it?
>>
>> Oh, and please - I understand the implications of doing such a thing, 
>> no worries, I still want to.
>>
> Since this wasn't allowed for NFSv2 and 3 (due to issues such as
> providing a T stable file handle), clients probably won't handle
> it well. In general, NFSv2 and 3 clients will get really confused
> when the fsid or fid changes and break in subtle ways if the file
> handle is not T stable (refers to that file only, including long
> after the file is deleted).

Is that really true?  It looked like the NFS handle was created by 
various file system goo, which could come up again some time in the 
future.  For instance, file a file systems inode table, rm all the 
files, do it again (with different data in the files).  Wouldn't the NFS 
handle look the same to the client then, but be a different file?  Or 
when we say 'file' do we mean 'inode' on a file system?

Also, by 'T stable', does 'T' mean 'time' here?

I'm not certain I completely understand why the clients would get 
confused.  Wouldn't it look something like this:

[File system->NFS server->NFS handle]
                |
                V
[NFS client->virtual file system->NFS server->NFS handle2]
                |
                V
[NFS Client->virtual file system->application]


> NFSv4 does allow mount point crossings (fsid to change), but some
> clients, such as Solaris10 are confused by it.
> 
> An easier solution might be to write a simple proxy that just forwards
> the RPC requests/replies to the actual server.

Thanks,
Eric