Problems with NFS exports

Problems with NFS exports

[Florian Weimer]

I'm seeing weired errors with nfsctl():

This works:

nfsservctl(NFSCTL_EXPORT, "deneb.enyo.de", "/mnt/storage/2/backup/deneb/tmp", makedev(3, 66), ino 167772288, uid 65534, gid 65534) = 0

But a subsequent call fails:

nfsservctl(NFSCTL_EXPORT, "deneb.enyo.de", "/mnt/storage/2/backup/deneb", makedev(3, 66), ino 150995072, uid 65534, gid 65534) = -1 EINVAL (Invalid argument)

I don't understand what makes the difference (the inode values are
correct).  This is kernel 2.4.18 with XFS support, and the directory
resides on an XFS file system.

Any ideas?

Re: Problems with NFS exports

[Florian Weimer]

Florian Weimer <fw@deneb.enyo.de> writes:

> I'm seeing weired errors with nfsctl():
>
> This works:
>
> nfsservctl(NFSCTL_EXPORT, "deneb.enyo.de", "/mnt/storage/2/backup/deneb/tmp", makedev(3, 66), ino 167772288, uid 65534, gid 65534) = 0
>
> But a subsequent call fails:
>
> nfsservctl(NFSCTL_EXPORT, "deneb.enyo.de", "/mnt/storage/2/backup/deneb", makedev(3, 66), ino 150995072, uid 65534, gid 65534) = -1 EINVAL (Invalid argument)
>
> I don't understand what makes the difference (the inode values are
> correct).  This is kernel 2.4.18 with XFS support, and the directory
> resides on an XFS file system.
>
> Any ideas?

(Full quote because of additional recipeint.)

It appears that a directory tree can only be exported once.  Is this
intentional?  If yes, the following patch should be applied (to
linux/fs/nfsd/export.c), so that the return value is more meaningful:

--- export.c	2002/08/07 09:22:11	1.1
+++ export.c	2002/08/07 09:22:28
@@ -219,6 +219,7 @@
 		goto finish;
 	}
 
+	err = -EBUSY;
 	if ((parent = exp_child(clp, dev, nd.dentry)) != NULL) {
 		dprintk("exp_export: export not valid (Rule 3).\n");
 		goto finish;


After this change, the userspace tools can issue are more meaningful
error message for this case.

Re: Problems with NFS exports

[Neil Brown]

On Wednesday August 7, fw@deneb.enyo.de wrote:
> Florian Weimer <fw@deneb.enyo.de> writes:
> 
> > I'm seeing weired errors with nfsctl():
> >
> > This works:
> >
> > nfsservctl(NFSCTL_EXPORT, "deneb.enyo.de", "/mnt/storage/2/backup/deneb/tmp", makedev(3, 66), ino 167772288, uid 65534, gid 65534) = 0
> >
> > But a subsequent call fails:
> >
> > nfsservctl(NFSCTL_EXPORT, "deneb.enyo.de", "/mnt/storage/2/backup/deneb", makedev(3, 66), ino 150995072, uid 65534, gid 65534) = -1 EINVAL (Invalid argument)
> >
> > I don't understand what makes the difference (the inode values are
> > correct).  This is kernel 2.4.18 with XFS support, and the directory
> > resides on an XFS file system.
> >
> > Any ideas?
> 
> (Full quote because of additional recipeint.)
> 
> It appears that a directory tree can only be exported once.  Is this
> intentional?  If yes, the following patch should be applied (to
> linux/fs/nfsd/export.c), so that the return value is more meaningful:

Probably better documentation in exports.5 would be just as useful.
And "BUSY" probably isn't correct ....
The rule is that you cannot export a directory and an ancestor of that
directory in the same filesystem.
/a/1 and /a/2 can both be exported, but not /a and /a/1.

Reason:  exporting "/a" means exporting that directoring and all
descendants of it in the same filesystem.
If you export /a with different flags than /a/1 it is ambiguous.

And personally, I doubt that there are very many situations where it
makes sense.

It would be possible to dis-ambiguate the ambiguity but it wouldn't be
very clean, and I really am not sure that it is worth the effort.

NeilBrown


> 
> --- export.c	2002/08/07 09:22:11	1.1
> +++ export.c	2002/08/07 09:22:28
> @@ -219,6 +219,7 @@
>  		goto finish;
>  	}
>  
> +	err = -EBUSY;
>  	if ((parent = exp_child(clp, dev, nd.dentry)) != NULL) {
>  		dprintk("exp_export: export not valid (Rule 3).\n");
>  		goto finish;
> 
> 
> After this change, the userspace tools can issue are more meaningful
> error message for this case.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Problems with NFS exports

[Florian Weimer]

Neil Brown <neilb@cse.unsw.edu.au> writes:

> Probably better documentation in exports.5 would be just as useful.

Maybe.

BTW, is it possible to export a directory tree under a different path,
using the kernel NFS daemon?

> And "BUSY" probably isn't correct ....

Why not? The ressource (the directory tree) is already being used, and
therefore the export fails.

> It would be possible to dis-ambiguate the ambiguity but it wouldn't be
> very clean, and I really am not sure that it is worth the effort.

Better error messages are always a good idea. :-)

Re: Problems with NFS exports

[Neil Brown]

On Wednesday August 7, fw@deneb.enyo.de wrote:
> Neil Brown <neilb@cse.unsw.edu.au> writes:
> 
> > Probably better documentation in exports.5 would be just as useful.
> 
> Maybe.
> 
> BTW, is it possible to export a directory tree under a different path,
> using the kernel NFS daemon?

Uhm... symlinks work.
Which is to say, the client can mount using a 'different path', though
they can also mount using the 'true' path.



> 
> > And "BUSY" probably isn't correct ....
> 
> Why not? The ressource (the directory tree) is already being used, and
> therefore the export fails.

I guess... I just feel it isn't really clear what it is that is
'busy'.

NeilBrown


> 
> > It would be possible to dis-ambiguate the ambiguity but it wouldn't be
> > very clean, and I really am not sure that it is worth the effort.
> 
> Better error messages are always a good idea. :-)

Can't disagree there.

NeilBrown

Re: Problems with NFS exports

[Florian Weimer]

Neil Brown <neilb@cse.unsw.edu.au> writes:

>> > And "BUSY" probably isn't correct ....
>> 
>> Why not? The ressource (the directory tree) is already being used, and
>> therefore the export fails.
>
> I guess... I just feel it isn't really clear what it is that is
> 'busy'.

And it implies that it is just a temporary error condition, not a
configuration issue.

Maybe EEXIST is better?