Re: NFSv4 pseudo filesystem

[David Chow <davidchow@shaolinmicro.com>]

Neil Brown wrote:

>On Friday May 10, kmsmith@umich.edu wrote:
>
>>  Proposal 3: Build up the pseudofs inside the 2.5 'nfsd' filesystem,
>>  say in a directory nfsd/pseudofs which is created when the nfsd
>>  filesystem is mounted.  The exportfs utility would be responsible
>>  for creating the necesary subdirectories, then hanging the exports
>>  off the leaves with mount --bind, before starting nfsd.
>>
>>As I see it, the disadvantage of proposal 3 is that it is a little
>>tricky to construct persistent filehandles ("persistent" in the sense
>>that an old filehandle is still recognize after the server is rebooted).
>>One solution would be to use an MD5 or SHA hash of the pathname as the
>>filehandle.  The hash could be computed in userspace and passed into
>>the kernel somehow.
>>
>
>I would go for 3, and don't care about persistent file handles.  Just
>use volatile filehandles for this bit of the namespace.
>
>NeilBrown
>-
>To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
I am a bit confused about compatibility of NFSv3, doesn't the nohide 
option allow to trigger an exported fs's (dir) subdirectory mount points 
to be automatically mounted by clients? If 2.5 is proposing the arbitary 
(fs=somepersistentnumber), how nohide is going to know whether the next 
fs's number? It is clear in 2.4 now we use the device major and minor 
numbers such that only block device fs are exportable. I think there 
were a long discussion about the fs= months ago to allow exporting non 
block device fs. I have worked hard on making my fs a fake block device 
fs in 2.4 which uses an arbitary block device number, but I don't think 
it is a good idea to drop the fs= implementation because many times we 
want to export non block device fs with a persisten t file handle. I 
don't think using arbitary devices for just because want to cope with 
NFS is a good idea. I think many of the system rely on the stateless and 
persistent design of NFS, since NFS is a de facto standard for Unixes, I 
am not happy to see NFSv4 break this.


regards,

David