All of lore.kernel.org
 help / color / mirror / Atom feed
* Small mountd bug & potential fix
@ 2005-03-03  1:01 Nathaniel Stahl
  0 siblings, 0 replies; 2+ messages in thread
From: Nathaniel Stahl @ 2005-03-03  1:01 UTC (permalink / raw)
  To: nfs

[-- Attachment #1: Type: text/plain, Size: 1582 bytes --]


We have a management product that can manage a Linux-based NFS server to 
allocate and export storage to managed servers.  (Then automatically 
mount the storage on those servers so it can be used)

I was seeing a problem where sometimes the directory I was exporting 
would not be mountable on the server it was exported to.

 >From the server machine's /var/log/messages:
Mar 1 10:49:53 fedora3 rpc.mountd: refused mount request from 
172.31.183.2 for
/mnt/NAS/exports/Levanta-1109702993-18 (/): not exported

But according to exportfs:

[root@fedora3 ~]# exportfs
/mnt/NAS/exports/Levanta-1109702992-17
172.31.183.2
/mnt/NAS/exports/Levanta-1109702993-18
172.31.183.2
/mnt/NAS/exports/Levanta-0
172.31.183.2

It looks like exportfs updates /var/lib/nfs/etab to inform mountd that 
there are new exports.

mountd decides whether to re-read etab based on whether the data 
modification time has changed since it was last read.  This fails if 
there are multiple updates in a second - quite possible on fast new 
machines if the NFS server is being programmatically controlled.  This 
patch updates mountd to track when it actually read the file, and 
compare that with the file's modification time.  If it last read the 
file at the same time it was last modified, re-read the file again in 
case there were other modifications later that second.  (Strictly 
speaking, the modification time equal check isn't necessary... only 
comparing the modification time to the current time, but I guess isn't a 
bad idea as added protection against someone playing with the clock).

-Nate


[-- Attachment #2: mountd-auth.patch --]
[-- Type: text/x-patch, Size: 786 bytes --]

--- /usr/src/redhat/SOURCES/nfs-utils-1.0.7/utils/mountd/auth.c	2004-12-05 16:46:40.000000000 -0800
+++ nfs-utils-1.0.7/utils/mountd/auth.c	2005-03-02 16:52:22.403733192 -0800
@@ -12,6 +12,7 @@
 #include <netinet/in.h>
 #include <arpa/inet.h>
 #include <errno.h>
+#include <time.h>
 #include "misc.h"
 #include "nfslib.h"
 #include "exportfs.h"
@@ -49,12 +50,14 @@
 {
 	struct stat		stb;
 	static time_t		last_modified = 0;
+	static time_t		last_read = 0;
 
 	if (stat(_PATH_ETAB, &stb) < 0)
 		xlog(L_FATAL, "couldn't stat %s", _PATH_ETAB);
-	if (stb.st_mtime == last_modified)
+	if ((stb.st_mtime == last_modified) && (last_read > last_modified))
 		return 0;
 	last_modified = stb.st_mtime;
+	last_read = time(NULL);
 
 	export_freeall();
 	memset(&my_client, 0, sizeof(my_client));

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Small mountd bug & potential fix.
@ 2005-03-11  4:59 Nathaniel Stahl
  0 siblings, 0 replies; 2+ messages in thread
From: Nathaniel Stahl @ 2005-03-11  4:59 UTC (permalink / raw)
  To: nfs

[-- Attachment #1: Type: text/plain, Size: 1814 bytes --]


Brief background: We have a management product that can manage a 
Linux-based NFS server to allocate and export storage to managed 
servers.  (Then automatically mount the storage on those servers so it 
can be used)

I was seeing a problem where sometimes the directory I was exporting 
would not be mountable on the server it was exported to.

 From the server machine's /var/log/messages:

Mar 1 10:49:53 fedora3 rpc.mountd: refused mount request from 
172.31.183.2 for /mnt/NAS/exports/Levanta-1109702993-18 (/): not exported

But according to exportfs:

[root@fedora3 ~]# exportfs
/mnt/NAS/exports/Levanta-1109702992-17
172.31.183.2
/mnt/NAS/exports/Levanta-1109702993-18
172.31.183.2
/mnt/NAS/exports/Levanta-0
172.31.183.2

After some debugging:

It looks like exportfs updates /var/lib/nfs/etab to inform mountd that 
there are new exports.

mountd decides whether to re-read etab based on whether the data 
modification time has changed since etab was last read.  This fails if 
there are multiple updates in a second - quite possible on fast new 
machines if the NFS server is being programmatically controlled.  This 
patch updates mountd to track when it actually read the file, and 
compare that with the file's modification time.  If it last read the 
file at the same time it was last modified, re-read the file again in 
case there were other modifications later that second.  (Strictly 
speaking, the modification time equality check isn't necessary... only 
comparing the modification time to the last read time, but I guess isn't 
a bad idea as added protection against someone playing with the clock).

-Nate

(I'd sent this once before, but wasn't a member of the list and it seems 
to have been eaten ;-P, so I apologize if the first copy eventually made 
it though and this is a duplicate)

[-- Attachment #2: mountd-auth.patch --]
[-- Type: text/x-patch, Size: 786 bytes --]

--- /usr/src/redhat/SOURCES/nfs-utils-1.0.7/utils/mountd/auth.c	2004-12-05 16:46:40.000000000 -0800
+++ nfs-utils-1.0.7/utils/mountd/auth.c	2005-03-02 16:52:22.403733192 -0800
@@ -12,6 +12,7 @@
 #include <netinet/in.h>
 #include <arpa/inet.h>
 #include <errno.h>
+#include <time.h>
 #include "misc.h"
 #include "nfslib.h"
 #include "exportfs.h"
@@ -49,12 +50,14 @@
 {
 	struct stat		stb;
 	static time_t		last_modified = 0;
+	static time_t		last_read = 0;
 
 	if (stat(_PATH_ETAB, &stb) < 0)
 		xlog(L_FATAL, "couldn't stat %s", _PATH_ETAB);
-	if (stb.st_mtime == last_modified)
+	if ((stb.st_mtime == last_modified) && (last_read > last_modified))
 		return 0;
 	last_modified = stb.st_mtime;
+	last_read = time(NULL);
 
 	export_freeall();
 	memset(&my_client, 0, sizeof(my_client));

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2005-03-11  4:59 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-03-11  4:59 Small mountd bug & potential fix Nathaniel Stahl
  -- strict thread matches above, loose matches on Subject: below --
2005-03-03  1:01 Nathaniel Stahl

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.