Changes to NFS filesystem exporting in 2.5.9

Changes to NFS filesystem exporting in 2.5.9

[Neil Brown]

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.

 Any questions - please ask.

NeilBrown

Re: Changes to NFS filesystem exporting in 2.5.9

[David Chow]

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

Re: Changes to NFS filesystem exporting in 2.5.9

[Neil Brown]

On Thursday April 25, davidchow@shaolinmicro.com wrote:
> 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?

In part.  It also contains "find_exported_dentry" which almost
every filesystem would use, directly or indirectly, as part of the
filehandle to dentry lookup.  It's task is to build the path from the
root down to a given dentry.

> 
> 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 ??

There is very little change needed to convert a fh_to_dentry
function into a decode_fh function.  I'll send you a copy of the patch
that makes the change for 'fat' when I get it done.  It should be
fairly typical.

> 
> 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?
> 

fh_to_dentry will definately stay as is in 2.4.
I may add s_export_op to 2.4 so that a file system can use either,
but filesystems will not be forced to use s_export_op before
2.5.something. 

NeilBrown

Re: Changes to NFS filesystem exporting in 2.5.9

[Chris Wright]

* Neil Brown (neilb@cse.unsw.edu.au) 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.

Neil, would you consider the patch below (against 2.5.10)?  It is essentially
cosmetic to make the comments more readable in 80 col. format and fix broken
kernel-doc bits.  I also add the minor dprintk change for crusty compilers
from akpm.

thanks.
-chris

===== fs/exportfs/expfs.c 1.1 vs edited =====
--- 1.1/fs/exportfs/expfs.c	Wed Apr 24 12:15:28 2002
+++ edited/fs/exportfs/expfs.c	Wed Apr 24 16:46:58 2002
@@ -3,39 +3,44 @@
 #include <linux/module.h>
 #include <linux/smp_lock.h>
 
+struct export_operations export_op_default;
+
+#define	CALL(ops,fun) ((ops->fun)?(ops->fun):export_op_default.fun)
+
+#define dprintk(fmt, args...) do{}while(0)
+
 /**
  * find_exported_dentry - helper routine to implement export_operations->decode_fh
  * @sb:		The &super_block identifying the filesystem
- * @obj:	An opaque identifier of the object to be found - passed to get_inode
+ * @obj:	An opaque identifier of the object to be found - passed to
+ *		get_inode
  * @parent:	An optional opqaue identifier of the parent of the object.
- * @acceptable:	A function used to test possible &dentries to see of they are acceptable
- * @context:	A parameter to @acceptable so that it knows on what basis to judge.
- *
- * find_exported_dentry is the central helper routine to enable file systems to provide
- * the decode_fh() export_operation.  It's main task is to take an &inode, find or create an
- * appropriate &dentry structure, and possibly splice this into the dcache in the
- * correct place.
+ * @acceptable:	A function used to test possible &dentries to see if they are
+ *		acceptable
+ * @context:	A parameter to @acceptable so that it knows on what basis to
+ *		judge.
  *
- * The decode_fh() operation provided by the filesystem should call find_exported_dentry()
- * with the same parameters that it received except that instead of the file handle fragment,
- * pointers to opaque identifiers for the object and optionally its parent are passed.
- * The default decode_fh routine passes one pointer to the start of the filehandle fragment, and
- * one 8 bytes into the fragment.  It is expected that most filesystems will take this
- * approach, though the offset to the parent identifier may well be different.
+ * find_exported_dentry is the central helper routine to enable file systems
+ * to provide the decode_fh() export_operation.  It's main task is to take
+ * an &inode, find or create an appropriate &dentry structure, and possibly
+ * splice this into the dcache in the correct place.
  *
- * find_exported_dentry() will call get_dentry to get an dentry pointer from the file system.  If
- * any &dentry in the d_alias list is acceptable, it will be returned.  Otherwise
- * find_exported_dentry() will attempt to splice a new &dentry into the dcache using get_name() and
- * get_parent() to find the appropriate place.
+ * The decode_fh() operation provided by the filesystem should call
+ * find_exported_dentry() with the same parameters that it received except
+ * that instead of the file handle fragment, pointers to opaque identifiers
+ * for the object and optionally its parent are passed.  The default decode_fh
+ * routine passes one pointer to the start of the filehandle fragment, and
+ * one 8 bytes into the fragment.  It is expected that most filesystems will
+ * take this approach, though the offset to the parent identifier may well be
+ * different.
  *
+ * find_exported_dentry() will call get_dentry to get an dentry pointer from
+ * the file system.  If any &dentry in the d_alias list is acceptable, it will
+ * be returned.  Otherwise find_exported_dentry() will attempt to splice a new
+ * &dentry into the dcache using get_name() and get_parent() to find the
+ * appropriate place.
  */
 
-struct export_operations export_op_default;
-
-#define	CALL(ops,fun) ((ops->fun)?(ops->fun):export_op_default.fun)
-
-#define dprintk(x, ...) do{}while(0)
-
 struct dentry *
 find_exported_dentry(struct super_block *sb, void *obj, void *parent,
 		     int (*acceptable)(void *context, struct dentry *de),
@@ -123,12 +128,12 @@
 	 * We then repeat.
 	 */
 
-	/* it is possible that a confused file system might not let us complete the
-	 * path to the root.  For example, if get_parent returns a directory
-	 * in which we cannot find a name for the child.  While this implies a very
-	 * sick filesystem we don't want it to cause knfsd to spin.  Hence the noprogress
-	 * counter.  If we go through the loop 10 times (2 is probably enough) without
-	 * getting anywhere, we just give up
+	/* it is possible that a confused file system might not let us complete 
+	 * the path to the root.  For example, if get_parent returns a directory
+	 * in which we cannot find a name for the child.  While this implies a
+	 * very sick filesystem we don't want it to cause knfsd to spin.  Hence
+	 * the noprogress counter.  If we go through the loop 10 times (2 is
+	 * probably enough) without getting anywhere, we just give up
 	 */
 	lock_kernel();
 	noprogress= 0;
@@ -155,8 +160,8 @@
 			 * to find parent and connect
 			 * note: racing with some other process renaming a
 			 * directory isn't much of a problem here.  If someone
-			 * renames the directory, it will end up properly connected,
-			 * which is what we want
+			 * renames the directory, it will end up properly
+			 * connected, which is what we want
 			 */
 			struct dentry *ppd;
 			struct dentry *npd;
@@ -178,8 +183,8 @@
 			if (err) {
 				dput(ppd);
 				if (err == -ENOENT)
-					/* some race between get_parent and get_name?
-					 * just try again
+					/* some race between get_parent and
+					 * get_name?  just try again
 					 */
 					continue;
 				dput(pd);
@@ -208,7 +213,7 @@
 			dput(npd);
 			dput(ppd);
 			if (IS_ROOT(pd)) {
-				/* something went wrong, we will have to give up */
+				/* something went wrong, we have to give up */
 				dput(pd);
 				break;
 			}
@@ -293,7 +298,8 @@
 
 
 struct getdents_callback {
-	char *name;		/* name that was found. It already points to a buffer NAME_MAX+1 is size */
+	char *name;		/* name that was found. It already points to a
+				   buffer NAME_MAX+1 is size */
 	unsigned long ino;	/* the inum we are looking for */
 	int found;		/* inode matched? */
 	int sequence;		/* sequence counter */
@@ -386,11 +392,11 @@
 	/* iget isn't really right if the inode is currently unallocated!!
 	 * This should really all be done inside each filesystem
 	 *
-	 * ext2fs' read_inode has been strengthed to return a bad_inode if the inode
-	 *   had been deleted.
+	 * ext2fs' read_inode has been strengthed to return a bad_inode if
+	 * the inode had been deleted.
 	 *
-	 * Currently we don't know the generation for parent directory, so a generation
-	 * of 0 means "accept any"
+	 * Currently we don't know the generation for parent directory, so
+	 * a generation of 0 means "accept any"
 	 */
 	struct inode *inode;
 	struct dentry *result;
@@ -437,10 +443,10 @@
 
 /**
  * export_encode_fh - default export_operations->encode_fh function
- * dentry:  the dentry to encode
- * fh:      where to store the file handle fragment
- * max_len: maximum length to store there
- * connectable: whether to store parent infomation
+ * @dentry:  the dentry to encode
+ * @fh:      where to store the file handle fragment
+ * @max_len: maximum length to store there
+ * @connectable: whether to store parent infomation
  *
  * This default encode_fh function assumes that the 32 inode number
  * is suitable for locating an inode, and that the generation number
@@ -474,11 +480,11 @@
 
 /**
  * export_decode_fh - default export_operations->decode_fh function
- * sb:  The superblock
- * fh:  pointer to the file handle fragment
- * fh_len: length of file handle fragment
- * acceptable: function for testing acceptability of dentrys
- * context:   context for @acceptable
+ * @sb:  The superblock
+ * @fh:  pointer to the file handle fragment
+ * @fh_len: length of file handle fragment
+ * @acceptable: function for testing acceptability of dentrys
+ * @context:   context for @acceptable
  *
  * This is the default decode_fh() function.
  * a fileid_type of 1 indicates that the filehandlefragment