Re: Changes to NFS filesystem exporting in 2.5.9

[David Chow <davidchow@shaolinmicro.com>]

Neil Brown wrote:

>Greetings.
>
> 2.5.9 brings with it some changes with how a filesystem co-operates
> with nfsd for exporting files, and particularly for converting
> between filehandles and dentries.
> 
> There is some fairly extensive documentation in
> Documentation/filesystems/Exporting but I thought it would be useful
> to outline it here and explain the direction that I am taking.
>
> There is now a s_export_op field in struct super_block which can
> point to a "struct export_operations" structure.
> This structure contains functions that are used for converting
> filehandles to dentries, and back again.
>
> The plan is to require this structure to be present for a filesystem
> to be exportable.  If nfsd finds that sb->s_export_op == NULL, it
> will not allow the filesystem to be exported.
> This means there is no risk of nfsd making assumptions about
> s_op->readinode that may not be valid.
>
> The new code that uses these operations takes a much cleaner approach
> to locking while messing with the dcache and so the
> s_nfsd_free_path_sem semaphore will not be needed anymore.  Instead,
> a little more is required of the ->lookup routine of a filesystem
> which is exportable.  The ->lookup routine must call d_splice_alias
> to attach a newly found inode to a dentry, so that if it is a
> directory and there is already a dentry attached, that one is used
> instead. 
>
> I plan to change all filesystems that currently use fh_to_dentry and
> dentry_to_fh so that they use export_operations, and modify a few
> filesystems that currently are exportable through iget abuse to be
> exported properly.  Then I will remove support for fh_to_dentry and
> for the iget abuse.  This will make nfsfh.c much smaller.
>
> Note that there is a new module: fs/exportfs which provides support
> routines for exporting filesystems.  The theory is that some
> protocols other the nfs might make use of these so they shouldn't be
> part of nfsd.  nfsd depends on this module, but filesystems don't
> (though they might indirectly use some of the code.
>
Are you saying exporfs module is some kind of generic_fh_to_dentry() ops 
for fs such as ext2/3 that can muck with iget() hacks?

We just properly implemented fh_to_dentry() in our fs for 2.4 and it 
works fine, so we just move our fh_to_dentry() op to the new 
sb->s_export_op->fh_to_dentry ??

What about compatibility and nature of fh_to_dentry() in 2.4? Is it 
going to keep unchange or you are planning to make changes?

>
> Any questions - please ask.
>
>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
>
David