People complain about the kernel messages when mounting NFS.
(Just like last time a new NFS version was introduced.)
It is perfectly normal to have mount newer than the kernel,
or the kernel newer than mount. No messages are needed or useful.
Andries
diff -uprN -X /linux/dontdiff a/fs/nfs/inode.c b/fs/nfs/inode.c
--- a/fs/nfs/inode.c 2004-02-18 11:33:18.000000000 +0100
+++ b/fs/nfs/inode.c 2004-03-29 20:53:28.000000000 +0200
@@ -1292,8 +1292,10 @@ static struct super_block *nfs_get_sb(st
memset(root->data+root->size, 0, sizeof(root->data)-root->size);
if (data->version != NFS_MOUNT_VERSION) {
+#if 0
printk("nfs warning: mount version %s than kernel\n",
data->version < NFS_MOUNT_VERSION ? "older" : "newer");
+#endif
if (data->version < 2)
data->namlen = 0;
if (data->version < 3)
@@ -1599,10 +1601,12 @@ static struct super_block *nfs4_get_sb(s
/* Zero out the NFS state stuff */
init_nfsv4_state(server);
+#if 0
if (data->version != NFS4_MOUNT_VERSION) {
printk("nfs warning: mount version %s than kernel\n",
data->version < NFS_MOUNT_VERSION ? "older" : "newer");
}
+#endif
p = nfs_copy_user_string(NULL, &data->hostname, 256);
if (IS_ERR(p))
P? m? , 29/03/2004 klokka 14:00, skreiv [email protected]:
> People complain about the kernel messages when mounting NFS.
> (Just like last time a new NFS version was introduced.)
> It is perfectly normal to have mount newer than the kernel,
> or the kernel newer than mount. No messages are needed or useful.
I disagree...
We should fix the printk to be KERN_NOTIFY so that you can filter them,
but otherwise there is *no way* to know whether or not you have support
for the features you are attempting to use.
People might get somewhat confused if they try to enable strong
security, and the kernel happily mounts the partition with AUTH_SYS, and
does nothing to warn them...
Cheers,
Trond
On Mon, Mar 29, 2004 at 02:11:20PM -0500, Trond Myklebust wrote:
> P? m? , 29/03/2004 klokka 14:00, skreiv [email protected]:
> > People complain about the kernel messages when mounting NFS.
> > (Just like last time a new NFS version was introduced.)
> > It is perfectly normal to have mount newer than the kernel,
> > or the kernel newer than mount. No messages are needed or useful.
>
> I disagree...
>
> We should fix the printk to be KERN_NOTIFY so that you can filter them,
> but otherwise there is *no way* to know whether or not you have support
> for the features you are attempting to use.
> People might get somewhat confused if they try to enable strong
> security, and the kernel happily mounts the partition with AUTH_SYS, and
> does nothing to warn them...
The features that are being used are used by layers of software.
If there is information to be passed, it should be passed to
that software, not printed in a syslog.
It is not the kernel's job to set policy and have an opinion about user mode setup.
Andries
P? m? , 29/03/2004 klokka 14:54, skreiv Andries Brouwer:
> The features that are being used are used by layers of software.
> If there is information to be passed, it should be passed to
> that software, not printed in a syslog.
> It is not the kernel's job to set policy and have an opinion about user mode setup.
What do you mean "setting policy"? Your program is attempting to use an
obsolete kernel ABI. Of course it should "have an opinion" about that...
The issue is merely whether or not to issue an EINVAL, in order to force
users to upgrade to an updated version of "mount":
For 2.7.x, I'm rather of a mind to do just that in order to finally
clean up the wretched struct nfs_mount and eliminate all the unused
backward-compatibilty crap, but doing so in the middle of 2.6.x is not
an option (particularly given that the SELinux mount changes came as
late as they did).
Cheers,
Trond
On Mon, Mar 29, 2004 at 06:24:13PM -0500, Trond Myklebust wrote:
> P? m? , 29/03/2004 klokka 14:54, skreiv Andries Brouwer:
>
> > The features that are being used are used by layers of software.
> > If there is information to be passed, it should be passed to
> > that software, not printed in a syslog.
> > It is not the kernel's job to set policy and have an opinion about user mode setup.
>
> What do you mean "setting policy"? Your program is attempting to use an
> obsolete kernel ABI. Of course it should "have an opinion" about that...
>
> The issue is merely whether or not to issue an EINVAL, in order to force
> users to upgrade to an updated version of "mount":
> For 2.7.x, I'm rather of a mind to do just that in order to finally
> clean up the wretched struct nfs_mount and eliminate all the unused
> backward-compatibilty crap, but doing so in the middle of 2.6.x is not
> an option (particularly given that the SELinux mount changes came as
> late as they did).
The present situation is that the kernel comes with messages when
mount is recent and the kernel is old, and also when the kernel
is recent and mount is old. I object to both.
Mount tries the latest version it knows about, when that fails
goes back to an earlier version until either the mount succeeds
or we give up. The same binary must work over a large range of
kernel versions.
If you think that it would be terrible to have a nfs-v3 mount
succeed on a kernel that knows about nfs-v4 then I would prefer
to change the name of the filesystem to nfs4.
Andries
P? m? , 29/03/2004 klokka 18:46, skreiv Andries Brouwer:
> The present situation is that the kernel comes with messages when
> mount is recent and the kernel is old, and also when the kernel
> is recent and mount is old. I object to both.
>
> Mount tries the latest version it knows about, when that fails
> goes back to an earlier version until either the mount succeeds
> or we give up. The same binary must work over a large range of
> kernel versions.
That will break functionality for the user, and sounds like a bug in
"mount". See my objection w.r.t. the user who thinks he is getting
secure authentication via RPCSEC_GSS.
> If you think that it would be terrible to have a nfs-v3 mount
> succeed on a kernel that knows about nfs-v4 then I would prefer
> to change the name of the filesystem to nfs4.
The changes you are complaining about have *NOTHING* whatsoever to do
with NFSv4, which already has its own filesystem name (yes: it is called
"nfs4") with its own struct nfs4_mount.
The 2 changes to the NFSv2/v3 mount structure are as follows:
int pseudoflavor; /* 5 */
char context[NFS_MAX_CONTEXT_LEN + 1]; /* 6 */
"pseudoflavor" adds support for the RPCSEC_GSS authentication flavours,
so that people can use it for improving NFSv2/v3 security.
"context" is an SELinux construct for passing their security context
information (whatever that may be) down to their private handler.
See? no NFSv4...
Cheers,
Trond
On Mon, Mar 29, 2004 at 07:20:53PM -0500, Trond Myklebust wrote:
> The changes you are complaining about have *NOTHING* whatsoever to do
Wait. It seems you think I am complaining about changes. I am not.
I am complaining about kernel messages.
They have been there since 0.99. Hardly changes, but they are annoying.
Mount has to go through all kinds of contortions to avoid these messages.
Has an explicit list of kernel versions built-in.
Yecch.
These messages should have been silenced ten years ago.
People complain.
> > Mount tries the latest version it knows about, when that fails
> > goes back to an earlier version until either the mount succeeds
> > or we give up. The same binary must work over a large range of
> > kernel versions.
>
> That will break functionality for the user, and sounds like a bug in
> "mount". See my objection w.r.t. the user who thinks he is getting
> secure authentication via RPCSEC_GSS.
If the user installs some distribution, like RedHat or SuSE,
then hopefully the distribution authors know what they are doing.
If the user invents his own system, hopefully he knows what he
is doing. A few random messages hardly improve matters here.
That is what I meant when I mentioned "policy".
And again - if the user asks for "mount -t nfs" she gets an
nfs mount. If you say that she might wish some particular kind
of nfs mount instead of just any, then she should have said so -
by adding some mount option, or by using a different filesystem type.
Andries
P? m? , 29/03/2004 klokka 20:33, skreiv Andries Brouwer:
> On Mon, Mar 29, 2004 at 07:20:53PM -0500, Trond Myklebust wrote:
>
> > The changes you are complaining about have *NOTHING* whatsoever to do
>
> Wait. It seems you think I am complaining about changes. I am not.
>
> I am complaining about kernel messages.
> They have been there since 0.99. Hardly changes, but they are annoying.
> Mount has to go through all kinds of contortions to avoid these messages.
> Has an explicit list of kernel versions built-in.
> Yecch.
Yecch is indeed appropriate, and I agree that this is bad. I really
regret not having created the "nfs3" filesystem all those years ago.
That would have made much of this compatibility argument mute.
I do have plans to fix this for 2.7. In particular I'd like to drop
support for "nfs", and separate it into "nfs2" and "nfs3", so that we
can have mount make sensible choices about what the server does or does
not support.
That should also allow us to modularize NFS a bit more in order to allow
people to drop v2 support (for instance) if they don't want to use it.
> These messages should have been silenced ten years ago.
> People complain.
They are supposed to. If they are seeing those messages, then they are
not up to date w.r.t. the binary interfaces.
Now if you can assure me that "util-linux" and all other programs that
use the mount interface can handle the EINVAL error, then fine: send me
the patch.
Otherwise, I see no alternative to the current situation: a silent
attempt to comply with a binary interface that the kernel does not
understand is clearly the wrong thing to do.
Cheers,
Trond