Alignment of NFS filehandles in 2.4.0
Hi Linus,
The following patch separates the representation of NFS filehandles
in the nfs mount structure from the internal kernel representation.
The motivation for doing this is Russell's complaint about alignment
issues on PPC architectures when casting from the generic filehandle
to knfsd filehandles.
This patch ensures that both the internal generic NFS filehandle and
the knfsd filehandles have integer alignment, thus rendering the cast
portable across architectures. It makes sure that we preserve the
current alignment within the nfs mount structure, hence we don't break
the userland mount programs.
Cheers,
Trond
diff -u --recursive --new-file linux-2.4.1-pre2/fs/nfs/inode.c
linux-2.4.1-fix_ppc/fs/nfs/inode.c
--- linux-2.4.1-pre2/fs/nfs/inode.c Tue Dec 12 02:46:04 2000
+++ linux-2.4.1-fix_ppc/fs/nfs/inode.c Fri Jan 12 01:07:38 2001
@@ -239,7 +239,7 @@
struct nfs_server *server;
struct rpc_xprt *xprt = NULL;
struct rpc_clnt *clnt = NULL;
- struct nfs_fh *root = >root, fh;
+ struct nfs_fh fh;
struct inode*root_inode = NULL;
unsigned intauthflavor;
struct sockaddr_in srvaddr;
@@ -251,7 +251,6 @@
if (!data)
goto out_miss_args;
- memset(, 0, sizeof(fh));
if (data->version != NFS_MOUNT_VERSION) {
printk("nfs warning: mount version %s than kernel\n",
data->version < NFS_MOUNT_VERSION ? "older" : "newer");
@@ -259,12 +258,21 @@
data->namlen = 0;
if (data->version < 3)
data->bsize = 0;
- if (data->version < 4) {
+ if (data->version < 4)
data->flags &= ~NFS_MOUNT_VER3;
- root =
- root->size = NFS2_FHSIZE;
- memcpy(root->data, data->old_root.data, NFS2_FHSIZE);
+ }
+
+ memset(, 0, sizeof(fh));
+ if (data->version < 4) {
+ fh.size = NFS2_FHSIZE;
+ memcpy(fh.data, data->old_root.data, NFS2_FHSIZE);
+ } else {
+ fh.size = (data->flags & NFS_MOUNT_VER3) ? data->root.size :
+NFS2_FHSIZE;
+ if (fh.size > sizeof(fh.data)) {
+ printk(KERN_WARNING "NFS: mount program passes invalid
+filehandle!\n");
+ goto out_no_remote;
}
+ memcpy(fh.data, data->root.data, fh.size);
}
/* We now require that the mount process passes the remote address */
@@ -363,9 +371,10 @@
* the root fh attributes.
*/
/* Did getting the root inode fail? */
- if (!(root_inode = nfs_get_root(sb, root))
+ if (!(root_inode = nfs_get_root(sb, ))
&& (data->flags & NFS_MOUNT_VER3)) {
data->flags &= ~NFS_MOUNT_VER3;
+ fh.size = NFS2_FHSIZE;
rpciod_down();
rpc_shutdown_client(server->client);
goto nfsv3_try_again;
@@ -380,7 +389,7 @@
sb->s_root->d_op = _dentry_operations;
/* Get some general file system info */
-if (server->rpc_ops->statfs(server, root, ) >= 0) {
+if (server->rpc_ops->statfs(server, , ) >= 0) {
if (server->namelen == 0)
server->namelen = fsinfo.namelen;
} else {
diff -u --recursive --new-file linux-2.4.1-pre2/include/linux/nfs.h
linux-2.4.1-fix_ppc/include/linux/nfs.h
--- linux-2.4.1-pre2/include/linux/nfs.hSat Apr 1 18:04:27 2000
+++ linux-2.4.1-fix_ppc/include/linux/nfs.h Fri Jan 12 01:09:59 2001
@@ -93,8 +93,8 @@
*/
#define NFS_MAXFHSIZE 64
struct nfs_fh {
- unsigned short size;
- unsigned char data[NFS_MAXFHSIZE];
+ unsigned intsize;
+ unsigned intdata[NFS_MAXFHSIZE / sizeof(int)];
};
/*
diff -u --recursive --new-file linux-2.4.1-pre2/include/linux/nfs3.h
linux-2.4.1-fix_ppc/include/linux/nfs3.h
--- linux-2.4.1-pre2/include/linux/nfs3.h Sat Apr 1 18:04:27 2000
+++ linux-2.4.1-fix_ppc/include/linux/nfs3.hFri Jan 12 01:09:35 2001
@@ -58,6 +58,11 @@
NF3BAD = 8
};
+struct nfs3_fh {
+ unsigned short size;
+ unsigned char data[NFS3_FHSIZE];
+};
+
#define NFS3_VERSION 3
#define NFS3PROC_NULL 0
#define NFS3PROC_GETATTR 1
diff -u --recursive --new-file linux-2.4.1-pre2/include/linux/nfs_mount.h
linux-2.4.1-fix_ppc/include/linux/nfs_mount.h
--- linux-2.4.1-pre2/include/linux/nfs_mount.h Fri Jan 5 21:55:12 2001
+++ linux-2.4.1-fix_ppc/include/linux/nfs_mount.h Fri Jan 12 01:34:12 2001
@@ -9,7 +9,8 @@
* structure passed from user-space to kernel-space during an nfs mount
*/
#include
-#include
+#include
+#include
/*
* WARNING! Do not delete or change the order of
Alignment of NFS filehandles in 2.4.0
Hi Linus,
The following patch separates the representation of NFS filehandles
in the nfs mount structure from the internal kernel representation.
The motivation for doing this is Russell's complaint about alignment
issues on PPC architectures when casting from the generic filehandle
to knfsd filehandles.
This patch ensures that both the internal generic NFS filehandle and
the knfsd filehandles have integer alignment, thus rendering the cast
portable across architectures. It makes sure that we preserve the
current alignment within the nfs mount structure, hence we don't break
the userland mount programs.
Cheers,
Trond
diff -u --recursive --new-file linux-2.4.1-pre2/fs/nfs/inode.c
linux-2.4.1-fix_ppc/fs/nfs/inode.c
--- linux-2.4.1-pre2/fs/nfs/inode.c Tue Dec 12 02:46:04 2000
+++ linux-2.4.1-fix_ppc/fs/nfs/inode.c Fri Jan 12 01:07:38 2001
@@ -239,7 +239,7 @@
struct nfs_server *server;
struct rpc_xprt *xprt = NULL;
struct rpc_clnt *clnt = NULL;
- struct nfs_fh *root = data-root, fh;
+ struct nfs_fh fh;
struct inode*root_inode = NULL;
unsigned intauthflavor;
struct sockaddr_in srvaddr;
@@ -251,7 +251,6 @@
if (!data)
goto out_miss_args;
- memset(fh, 0, sizeof(fh));
if (data-version != NFS_MOUNT_VERSION) {
printk("nfs warning: mount version %s than kernel\n",
data-version NFS_MOUNT_VERSION ? "older" : "newer");
@@ -259,12 +258,21 @@
data-namlen = 0;
if (data-version 3)
data-bsize = 0;
- if (data-version 4) {
+ if (data-version 4)
data-flags = ~NFS_MOUNT_VER3;
- root = fh;
- root-size = NFS2_FHSIZE;
- memcpy(root-data, data-old_root.data, NFS2_FHSIZE);
+ }
+
+ memset(fh, 0, sizeof(fh));
+ if (data-version 4) {
+ fh.size = NFS2_FHSIZE;
+ memcpy(fh.data, data-old_root.data, NFS2_FHSIZE);
+ } else {
+ fh.size = (data-flags NFS_MOUNT_VER3) ? data-root.size :
+NFS2_FHSIZE;
+ if (fh.size sizeof(fh.data)) {
+ printk(KERN_WARNING "NFS: mount program passes invalid
+filehandle!\n");
+ goto out_no_remote;
}
+ memcpy(fh.data, data-root.data, fh.size);
}
/* We now require that the mount process passes the remote address */
@@ -363,9 +371,10 @@
* the root fh attributes.
*/
/* Did getting the root inode fail? */
- if (!(root_inode = nfs_get_root(sb, root))
+ if (!(root_inode = nfs_get_root(sb, fh))
(data-flags NFS_MOUNT_VER3)) {
data-flags = ~NFS_MOUNT_VER3;
+ fh.size = NFS2_FHSIZE;
rpciod_down();
rpc_shutdown_client(server-client);
goto nfsv3_try_again;
@@ -380,7 +389,7 @@
sb-s_root-d_op = nfs_dentry_operations;
/* Get some general file system info */
-if (server-rpc_ops-statfs(server, root, fsinfo) = 0) {
+if (server-rpc_ops-statfs(server, fh, fsinfo) = 0) {
if (server-namelen == 0)
server-namelen = fsinfo.namelen;
} else {
diff -u --recursive --new-file linux-2.4.1-pre2/include/linux/nfs.h
linux-2.4.1-fix_ppc/include/linux/nfs.h
--- linux-2.4.1-pre2/include/linux/nfs.hSat Apr 1 18:04:27 2000
+++ linux-2.4.1-fix_ppc/include/linux/nfs.h Fri Jan 12 01:09:59 2001
@@ -93,8 +93,8 @@
*/
#define NFS_MAXFHSIZE 64
struct nfs_fh {
- unsigned short size;
- unsigned char data[NFS_MAXFHSIZE];
+ unsigned intsize;
+ unsigned intdata[NFS_MAXFHSIZE / sizeof(int)];
};
/*
diff -u --recursive --new-file linux-2.4.1-pre2/include/linux/nfs3.h
linux-2.4.1-fix_ppc/include/linux/nfs3.h
--- linux-2.4.1-pre2/include/linux/nfs3.h Sat Apr 1 18:04:27 2000
+++ linux-2.4.1-fix_ppc/include/linux/nfs3.hFri Jan 12 01:09:35 2001
@@ -58,6 +58,11 @@
NF3BAD = 8
};
+struct nfs3_fh {
+ unsigned short size;
+ unsigned char data[NFS3_FHSIZE];
+};
+
#define NFS3_VERSION 3
#define NFS3PROC_NULL 0
#define NFS3PROC_GETATTR 1
diff -u --recursive --new-file linux-2.4.1-pre2/include/linux/nfs_mount.h
linux-2.4.1-fix_ppc/include/linux/nfs_mount.h
--- linux-2.4.1-pre2/include/linux/nfs_mount.h Fri Jan 5 21:55:12 2001
+++ linux-2.4.1-fix_ppc/include/linux/nfs_mount.h Fri Jan 12 01:34:12 2001
@@ -9,7 +9,8 @@
* structure passed from user-space to kernel-space during an nfs mount
*/
#include linux/in.h
-#include linux/nfs.h
+#include linux/nfs2.h
+#include linux/nfs3.h
/*
* WARNING! Do not
Re: Even slower NFS mounting with 2.4.0
> Hmm... How should we respond to that sort of thing? In principle the > NFS layer supposes that if we have a hard mount, then unreachable > ports etc are a temporary problem, and we should wait them out. (In > fact, I've made an RPC 'ping' routine that improves on that behaviour > but which unfortunately didn't make it into 2.4.0.) That makes reasonable sense once mounted. I think mount needs to be polite until it decides the mount is made > If we want to check that the port is reachable at the moment when we > mount, I think we should concentrate on making 'mount' more > intelligent. Perhaps have it RPC-ping the various ports (including the > local portmapper when we specify locking)? That would work. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Even slower NFS mounting with 2.4.0
> " " == Alan Cox <[EMAIL PROTECTED]> writes: >> > This is caused by 2.3/2.4 changes in the network code error >> > reporting of unreachables with UDP I suspect. It looks like >> > the NFS code hasn't yet caught up with the error notification >> > stuff >> >> No. It was the fact that he was forgetting to start the >> portmapper before mounting an NFS partition with locking >> enabled. > Its both. If you support the error notification then you see > the PORT UNREACH and you abandon early even if the user makes > that error Hmm... How should we respond to that sort of thing? In principle the NFS layer supposes that if we have a hard mount, then unreachable ports etc are a temporary problem, and we should wait them out. (In fact, I've made an RPC 'ping' routine that improves on that behaviour but which unfortunately didn't make it into 2.4.0.) If we want to check that the port is reachable at the moment when we mount, I think we should concentrate on making 'mount' more intelligent. Perhaps have it RPC-ping the various ports (including the local portmapper when we specify locking)? Cheers, Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Even slower NFS mounting with 2.4.0
" " == Alan Cox [EMAIL PROTECTED] writes: This is caused by 2.3/2.4 changes in the network code error reporting of unreachables with UDP I suspect. It looks like the NFS code hasn't yet caught up with the error notification stuff No. It was the fact that he was forgetting to start the portmapper before mounting an NFS partition with locking enabled. Its both. If you support the error notification then you see the PORT UNREACH and you abandon early even if the user makes that error Hmm... How should we respond to that sort of thing? In principle the NFS layer supposes that if we have a hard mount, then unreachable ports etc are a temporary problem, and we should wait them out. (In fact, I've made an RPC 'ping' routine that improves on that behaviour but which unfortunately didn't make it into 2.4.0.) If we want to check that the port is reachable at the moment when we mount, I think we should concentrate on making 'mount' more intelligent. Perhaps have it RPC-ping the various ports (including the local portmapper when we specify locking)? Cheers, Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Even slower NFS mounting with 2.4.0
Hmm... How should we respond to that sort of thing? In principle the NFS layer supposes that if we have a hard mount, then unreachable ports etc are a temporary problem, and we should wait them out. (In fact, I've made an RPC 'ping' routine that improves on that behaviour but which unfortunately didn't make it into 2.4.0.) That makes reasonable sense once mounted. I think mount needs to be polite until it decides the mount is made If we want to check that the port is reachable at the moment when we mount, I think we should concentrate on making 'mount' more intelligent. Perhaps have it RPC-ping the various ports (including the local portmapper when we specify locking)? That would work. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Even slower NFS mounting with 2.4.0
> I called the mount command five minutes before the final message above. > I tried NFS with and without NFSv3 code, with no change at all. This is caused by 2.3/2.4 changes in the network code error reporting of unreachables with UDP I suspect. It looks like the NFS code hasn't yet caught up with the error notification stuff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Even slower NFS mounting with 2.4.0
Christian Ullrich writes: > About three weeks ago, I complained loudly about very slow NFS mounts > involving a 2.2.17 server and a 2.2.18 client. > > Today, I complain loudly about *extremely* slow NFS mounts > with the very same server and the same client now running 2.4.0. In all cases, you need to either: 1. Provide the option "nolock" to turn of NFS file locking (which means that things like elm can't lock mailboxes and will get upset if the mailboxes are on a NFS partition). 2. before running the mount command: a) make sure the loopback interface is up and running b) ensure that the portmapper (called portmap or rpc.portmap) is running. _ |_| - ---+---+- | | Russell King[EMAIL PROTECTED] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ - /\\\ | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Even slower NFS mounting with 2.4.0
* Christian Ullrich wrote on Saturday, 2000-01-06: > Using 2.2.18, every [NFS] mount took about 15 seconds, now, using 2.4.0, > every mount takes exactly five minutes, which is way too long. Ok, it's fixed now. Thanks to all of you, and especially the (right now) three people who gave me the helpful hint to start the portmapper on the client as well. l-k is great! -- Christian UllrichRegistrierter Linux-User #125183 "Sie können nach R'ed'mond fliegen -- aber Sie werden sterben" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Even slower NFS mounting with 2.4.0
* Christian Ullrich wrote on Saturday, 2000-01-06: Using 2.2.18, every [NFS] mount took about 15 seconds, now, using 2.4.0, every mount takes exactly five minutes, which is way too long. Ok, it's fixed now. Thanks to all of you, and especially the (right now) three people who gave me the helpful hint to start the portmapper on the client as well. l-k is great! -- Christian UllrichRegistrierter Linux-User #125183 "Sie können nach R'ed'mond fliegen -- aber Sie werden sterben" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Even slower NFS mounting with 2.4.0
Christian Ullrich writes: About three weeks ago, I complained loudly about very slow NFS mounts involving a 2.2.17 server and a 2.2.18 client. Today, I complain loudly about *extremely* slow NFS mounts with the very same server and the same client now running 2.4.0. In all cases, you need to either: 1. Provide the option "nolock" to turn of NFS file locking (which means that things like elm can't lock mailboxes and will get upset if the mailboxes are on a NFS partition). 2. before running the mount command: a) make sure the loopback interface is up and running b) ensure that the portmapper (called portmap or rpc.portmap) is running. _ |_| - ---+---+- | | Russell King[EMAIL PROTECTED] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ - /\\\ | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Even slower NFS mounting with 2.4.0
I called the mount command five minutes before the final message above. I tried NFS with and without NFSv3 code, with no change at all. This is caused by 2.3/2.4 changes in the network code error reporting of unreachables with UDP I suspect. It looks like the NFS code hasn't yet caught up with the error notification stuff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Even slower NFS mounting with 2.4.0
Hrm. I'm not seeing this problem on my setups. Did you send details about your configurationlast time .. Could you resend? Christian Ullrich wrote: > > Hello! > > About three weeks ago, I complained loudly about very slow NFS mounts > involving a 2.2.17 server and a 2.2.18 client. > > Today, I complain loudly about *extremely* slow NFS mounts > with the very same server and the same client now running 2.4.0. > > Using 2.2.18, every mount took about 15 seconds, now, using 2.4.0, > every mount takes exactly five minutes, which is way too long. > > According to syslog, the server begins and completes its operations > related to the mount in under one second, so it seems to me that > mount on the client just takes a nap in D state. > Although the messages in the client's syslog look critical to me, > once the fs is mounted, it works fine. > > Syslog on client: > > Jan 6 00:18:06 c kernel: portmap: server localhost not responding, timed out > Jan 6 00:19:46 c kernel: portmap: server localhost not responding, timed out > Jan 6 00:19:46 c kernel: lockd_up: makesock failed, error=-5 > Jan 6 00:21:26 c kernel: portmap: server localhost not responding, timed out > > I called the mount command five minutes before the final message above. > > I tried NFS with and without NFSv3 code, with no change at all. > > Please help me. -- = Mohammad A. Haque http://www.haque.net/ [EMAIL PROTECTED] "Alcohol and calculus don't mix. Project Lead Don't drink and derive." --Unknown http://wm.themes.org/ [EMAIL PROTECTED] = - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Even slower NFS mounting with 2.4.0
Hello! About three weeks ago, I complained loudly about very slow NFS mounts involving a 2.2.17 server and a 2.2.18 client. Today, I complain loudly about *extremely* slow NFS mounts with the very same server and the same client now running 2.4.0. Using 2.2.18, every mount took about 15 seconds, now, using 2.4.0, every mount takes exactly five minutes, which is way too long. According to syslog, the server begins and completes its operations related to the mount in under one second, so it seems to me that mount on the client just takes a nap in D state. Although the messages in the client's syslog look critical to me, once the fs is mounted, it works fine. Syslog on client: Jan 6 00:18:06 c kernel: portmap: server localhost not responding, timed out Jan 6 00:19:46 c kernel: portmap: server localhost not responding, timed out Jan 6 00:19:46 c kernel: lockd_up: makesock failed, error=-5 Jan 6 00:21:26 c kernel: portmap: server localhost not responding, timed out I called the mount command five minutes before the final message above. I tried NFS with and without NFSv3 code, with no change at all. Please help me. -- Christian UllrichRegistrierter Linux-User #125183 "Sie können nach R'ed'mond fliegen -- aber Sie werden sterben" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Even slower NFS mounting with 2.4.0
Hello! About three weeks ago, I complained loudly about very slow NFS mounts involving a 2.2.17 server and a 2.2.18 client. Today, I complain loudly about *extremely* slow NFS mounts with the very same server and the same client now running 2.4.0. Using 2.2.18, every mount took about 15 seconds, now, using 2.4.0, every mount takes exactly five minutes, which is way too long. According to syslog, the server begins and completes its operations related to the mount in under one second, so it seems to me that mount on the client just takes a nap in D state. Although the messages in the client's syslog look critical to me, once the fs is mounted, it works fine. Syslog on client: Jan 6 00:18:06 c kernel: portmap: server localhost not responding, timed out Jan 6 00:19:46 c kernel: portmap: server localhost not responding, timed out Jan 6 00:19:46 c kernel: lockd_up: makesock failed, error=-5 Jan 6 00:21:26 c kernel: portmap: server localhost not responding, timed out I called the mount command five minutes before the final message above. I tried NFS with and without NFSv3 code, with no change at all. Please help me. -- Christian UllrichRegistrierter Linux-User #125183 "Sie können nach R'ed'mond fliegen -- aber Sie werden sterben" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Even slower NFS mounting with 2.4.0
Hrm. I'm not seeing this problem on my setups. Did you send details about your configurationlast time .. Could you resend? Christian Ullrich wrote: Hello! About three weeks ago, I complained loudly about very slow NFS mounts involving a 2.2.17 server and a 2.2.18 client. Today, I complain loudly about *extremely* slow NFS mounts with the very same server and the same client now running 2.4.0. Using 2.2.18, every mount took about 15 seconds, now, using 2.4.0, every mount takes exactly five minutes, which is way too long. According to syslog, the server begins and completes its operations related to the mount in under one second, so it seems to me that mount on the client just takes a nap in D state. Although the messages in the client's syslog look critical to me, once the fs is mounted, it works fine. Syslog on client: Jan 6 00:18:06 c kernel: portmap: server localhost not responding, timed out Jan 6 00:19:46 c kernel: portmap: server localhost not responding, timed out Jan 6 00:19:46 c kernel: lockd_up: makesock failed, error=-5 Jan 6 00:21:26 c kernel: portmap: server localhost not responding, timed out I called the mount command five minutes before the final message above. I tried NFS with and without NFSv3 code, with no change at all. Please help me. -- = Mohammad A. Haque http://www.haque.net/ [EMAIL PROTECTED] "Alcohol and calculus don't mix. Project Lead Don't drink and derive." --Unknown http://wm.themes.org/ [EMAIL PROTECTED] = - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: nfs on a 2.4.0
> " " == johna <[EMAIL PROTECTED]> writes: > Rootfs works fine, but attempting to mount other directories > via nfs causes problems. Error messages like : RPC: sendmsg > returned error 101, nfs warning: mount version is older than The 'sendmsg' error means you're trying to mount with NLM locking enabled before having started the portmapper. That's a no-no: always has been, and always will be. It 'worked' (not) in 2.2.x due to a hack. If you don't need locking, mount using the 'nolock' option. If you do, make sure that your startup scripts fire up portmap and rpc.statd before you mount your extra disks. As for the necessary 'mount' changes; they have already gone into the standard util-linux package. Just pick up the latest version from your nearest mirror site, or from Andries' master site: ftp://ftp.win.tue.nl/pub/linux/utils/util-linux/ Cheers, Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: nfs on a 2.4.0
" " == johna [EMAIL PROTECTED] writes: Rootfs works fine, but attempting to mount other directories via nfs causes problems. Error messages like : RPC: sendmsg returned error 101, nfs warning: mount version is older than The 'sendmsg' error means you're trying to mount with NLM locking enabled before having started the portmapper. That's a no-no: always has been, and always will be. It 'worked' (not) in 2.2.x due to a hack. If you don't need locking, mount using the 'nolock' option. If you do, make sure that your startup scripts fire up portmap and rpc.statd before you mount your extra disks. As for the necessary 'mount' changes; they have already gone into the standard util-linux package. Just pick up the latest version from your nearest mirror site, or from Andries' master site: ftp://ftp.win.tue.nl/pub/linux/utils/util-linux/ Cheers, Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
nfs on a 2.4.0
I'm running linux-2.4.0-test9-pre7-riel on a 386 netstation, using etherboot and rootfs. Rootfs works fine. But ... Normally I mount /bin, /var, /etc, /lib (minimal) via rootfs, where they are required for booting, and operation of the box, and once booting has started, I mount /usr, /sbin and so on via conventional nfs, as there are needed for read only they can be shared amongst many netstations. Rootfs works fine, but attempting to mount other directories via nfs causes problems. Error messages like : RPC: sendmsg returned error 101, nfs warning: mount version is older than kernel, lockd_up: no pid, 7 users appear during the attempt at the netstation; there are no error indications on logs at the nfs hosting machine. I can sometimes read /sbin, but at other times the 386 box locks up; there seems to be some nfs info from the hosting machine, but the netstation seems to ignore it. It is possible I need a "newer" mount to mount the file system effectively on a 2.4.0 kernel; rootfs which relies only on stuff inside the kernel, works OK. If this is the case, where would you find such a binary ? I'm not on the kernel list; please forward replies to my email address. Thanks, -- John August Some of us are paying for sins we have committed. Others are paying for sins we still have to commit. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
nfs on a 2.4.0
I'm running linux-2.4.0-test9-pre7-riel on a 386 netstation, using etherboot and rootfs. Rootfs works fine. But ... Normally I mount /bin, /var, /etc, /lib (minimal) via rootfs, where they are required for booting, and operation of the box, and once booting has started, I mount /usr, /sbin and so on via conventional nfs, as there are needed for read only they can be shared amongst many netstations. Rootfs works fine, but attempting to mount other directories via nfs causes problems. Error messages like : RPC: sendmsg returned error 101, nfs warning: mount version is older than kernel, lockd_up: no pid, 7 users appear during the attempt at the netstation; there are no error indications on logs at the nfs hosting machine. I can sometimes read /sbin, but at other times the 386 box locks up; there seems to be some nfs info from the hosting machine, but the netstation seems to ignore it. It is possible I need a "newer" mount to mount the file system effectively on a 2.4.0 kernel; rootfs which relies only on stuff inside the kernel, works OK. If this is the case, where would you find such a binary ? I'm not on the kernel list; please forward replies to my email address. Thanks, -- John August Some of us are paying for sins we have committed. Others are paying for sins we still have to commit. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
