* 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* 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
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.