From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Chow Subject: Re: Changes to NFS filesystem exporting in 2.5.9 Date: Thu, 25 Apr 2002 01:04:12 +0800 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <3CC6E58C.3040404@shaolinmicro.com> References: <15558.18023.887129.752121@notabene.cse.unsw.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org Return-path: To: Neil Brown List-Id: linux-fsdevel.vger.kernel.org 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