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?
Florian Weimer <[email protected]> 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.
On Wednesday August 7, [email protected] wrote:
> Florian Weimer <[email protected]> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Neil Brown <[email protected]> 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. :-)
On Wednesday August 7, [email protected] wrote:
> Neil Brown <[email protected]> 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
Neil Brown <[email protected]> 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?