Hi:
I am seeing an unusual problem on running nfs server on mips. Over Intel
this does not happen. When I run exportfs -a on the server when the
clients have already mounted their nfs filesystem, the kernel exports
table as can be seen from /proc/fs/nfs/exports gets completely flushed
out. We (me and one another colleague) have done some digging (mostly
looking into nfsutils codebase) and it looks like a kernel side issue.
We had also asked folks in the linux-mips mailing list, but apparently
no one has any clue. I am just hoping that those who are more familiar
with the user level and kernel side of nfs might me something more to
chew on. If you can give any suggestions that will be really useful. If
you think the information I provided is not enough, I can give you any
other information you need in this regard.
We are using mips SB1 64 bit processor and running a 2.6.17 kernel from
linux-mips.org.
Thanks in advance,
Ani
On Wed, Jan 30, 2008 at 05:34:13PM -0800, Anirban Sinha wrote:
> Hi:
>
> I am seeing an unusual problem on running nfs server on mips. Over Intel
> this does not happen. When I run exportfs -a on the server when the
> clients have already mounted their nfs filesystem, the kernel exports
> table as can be seen from /proc/fs/nfs/exports gets completely flushed
> out. We (me and one another colleague) have done some digging (mostly
> looking into nfsutils codebase) and it looks like a kernel side issue.
> We had also asked folks in the linux-mips mailing list, but apparently
> no one has any clue. I am just hoping that those who are more familiar
> with the user level and kernel side of nfs might me something more to
> chew on. If you can give any suggestions that will be really useful. If
> you think the information I provided is not enough, I can give you any
> other information you need in this regard.
Does the MIPS box have the /proc/fs/nfsd/ filesystem mounted?
Perhaps you could try
1) running exportfs under strace. I suggest
strace -o /tmp/s.log -s 1024 exportfs ...
2) AND enabling kernel debug messages
rpcdebug -m nfsd -s export
rpcdebug -m rpc -s cache
--
Greg Banks, R&D Software Engineer, SGI Australian Software Group.
The cake is *not* a lie.
I don't speak for SGI.
Hi Greg:
Thanks for replying. Here goes my response:
> -----Original Message-----
> From: Greg Banks [mailto:[email protected]]
> Sent: Wednesday, January 30, 2008 6:37 PM
> To: Anirban Sinha
> Cc: [email protected]
> Subject: Re: kernel exports table flushes out on running exportfs -a
> over mips
>
> On Wed, Jan 30, 2008 at 05:34:13PM -0800, Anirban Sinha wrote:
> > Hi:
> >
> > I am seeing an unusual problem on running nfs server on mips. Over
> Intel
> > this does not happen. When I run exportfs -a on the server when the
> > clients have already mounted their nfs filesystem, the kernel
exports
> > table as can be seen from /proc/fs/nfs/exports gets completely
> flushed
> > out. We (me and one another colleague) have done some digging
(mostly
> > looking into nfsutils codebase) and it looks like a kernel side
> issue.
> > We had also asked folks in the linux-mips mailing list, but
> apparently
> > no one has any clue. I am just hoping that those who are more
> familiar
> > with the user level and kernel side of nfs might me something more
to
> > chew on. If you can give any suggestions that will be really useful.
> If
> > you think the information I provided is not enough, I can give you
> any
> > other information you need in this regard.
>
> Does the MIPS box have the /proc/fs/nfsd/ filesystem mounted?
Ahh, I see what you mean. Yes, it is mounted, both /proc/fs/nfsd and
/proc/fs/nfs. However, I can see from the code that check_new_cache()
checks for a file "filehandle" which does not exist in that location. To
be dead sure, I instrumented the code to insert a perror and it returns
"no such file or directory". The new_cache flag remains 0. Is this some
sort of kernel bug?
> Perhaps you could try
>
> 1) running exportfs under strace. I suggest
> strace -o /tmp/s.log -s 1024 exportfs ...
Strace does not work in our environment as it has not been properly
ported to mips.
> 2) AND enabling kernel debug messages
> rpcdebug -m nfsd -s export
> rpcdebug -m rpc -s cache
I attach the dmesg output after enabling those flags. Zeugma-x-y are the
clients to this server. Not sure if it means anything suspicious.
Ani
>
>
> --
> Greg Banks, R&D Software Engineer, SGI Australian Software Group.
> The cake is *not* a lie.
> I don't speak for SGI.
Hi:
I did some extensive digging into the codebase and I believe I have the
reason
why exportfs -a flushes out the caches after NFS clients have mounted
the NFS filesystem.
The analysis is complicated, but here's
the crux of the matter:
There is a difference in the /etc/exports and the kernel maintained
cache. The
difference is that in /etc/exports, we use anonymous clients (*) whereas
kernel
maintains a FQDN client names in its exports cache (see attached file).
This
difference (the parsing code client_gettype() specifically checks for a
* or an IP or hostname among other things and based on that creates two
different types of caches) is causing the nfs codebase to recreate new
in core exports entries (the second time when we issue "exportfs -a")
after parsing /proc/fs/nfs/export. Immediately later, it then throws
these away (for these
newly created entries, m_mayexport = 0 and m_exported = 1 in function
xtab_read()). For details, see the logic in exports_update_one():
if (exp->m_exported && !exp->m_mayexport) { ... unexporting ...}
Since both the anonymous and FQDN entries are essentially the same, this
results in blowing away the existing kernel exports table.
My question is, is there a elegant solution to this problem without
simply using FQDN in /etc/exports? I have confirmed that the problem
does not occur when both the in kernel and /etc/exports tables have same
entries (both * or both FQDN).
Cheers,
Ani
> -----Original Message-----
> From: [email protected] [mailto:linux-nfs-
> [email protected]] On Behalf Of Anirban Sinha
> Sent: Thursday, January 31, 2008 2:09 PM
> To: Greg Banks
> Cc: [email protected]
> Subject: RE: kernel exports table flushes out on running exportfs -a
> over mips
>
> Hi Greg:
>
> Thanks for replying. Here goes my response:
>
> > -----Original Message-----
> > From: Greg Banks [mailto:[email protected]]
> > Sent: Wednesday, January 30, 2008 6:37 PM
> > To: Anirban Sinha
> > Cc: [email protected]
> > Subject: Re: kernel exports table flushes out on running exportfs -a
> > over mips
> >
> > On Wed, Jan 30, 2008 at 05:34:13PM -0800, Anirban Sinha wrote:
> > > Hi:
> > >
> > > I am seeing an unusual problem on running nfs server on mips. Over
> > Intel
> > > this does not happen. When I run exportfs -a on the server when
the
> > > clients have already mounted their nfs filesystem, the kernel
> exports
> > > table as can be seen from /proc/fs/nfs/exports gets completely
> > flushed
> > > out. We (me and one another colleague) have done some digging
> (mostly
> > > looking into nfsutils codebase) and it looks like a kernel side
> > issue.
> > > We had also asked folks in the linux-mips mailing list, but
> > apparently
> > > no one has any clue. I am just hoping that those who are more
> > familiar
> > > with the user level and kernel side of nfs might me something more
> to
> > > chew on. If you can give any suggestions that will be really
> useful.
> > If
> > > you think the information I provided is not enough, I can give you
> > any
> > > other information you need in this regard.
> >
> > Does the MIPS box have the /proc/fs/nfsd/ filesystem mounted?
>
> Ahh, I see what you mean. Yes, it is mounted, both /proc/fs/nfsd and
> /proc/fs/nfs. However, I can see from the code that check_new_cache()
> checks for a file "filehandle" which does not exist in that location.
> To be dead sure, I instrumented the code to insert a perror and it
> returns "no such file or directory". The new_cache flag remains 0. Is
> this some sort of kernel bug?
>
>
> > Perhaps you could try
> >
> > 1) running exportfs under strace. I suggest
> > strace -o /tmp/s.log -s 1024 exportfs ...
>
> Strace does not work in our environment as it has not been properly
> ported to mips.
>
> > 2) AND enabling kernel debug messages
> > rpcdebug -m nfsd -s export
> > rpcdebug -m rpc -s cache
>
> I attach the dmesg output after enabling those flags. Zeugma-x-y are
> the clients to this server. Not sure if it means anything suspicious.
>
> Ani
>
>
> >
> >
> > --
> > Greg Banks, R&D Software Engineer, SGI Australian Software Group.
> > The cake is *not* a lie.
> > I don't speak for SGI.
At a higher level, in general, I think the kernel exports table need not
match /etc/exports at all. When we run "exportfs -a" again, what the
codebase intends to do is the following:
1. Scan /etc/exports and verify that an entry exists (create one if not)
in its in core exports table. Mark each of these as "may_be_exported".
2. Scan /proc and see that each of the entries there has a corresponding
entry in the in core exports table (a matching operation). If not,
create a new entry. Mark all entries from /proc as "exported".
3. If there are any entries that are *not* "may_be_exported" and yet
"exported", then issue the right rpc through /proc/net/sunrpc/<app
cache> to delete that entry from the kernel table.
In this case, the matching operation does not detect that a * in the
hostname essentially means *anyone* can mount the volume, regardless of
their specific names. As a result, duplicate entries are created and
ultimately everything gets flushed out :(
Any elegant suggestion/bugfix will be really appreciated.
Ani
> -----Original Message-----
> From: Anirban Sinha
> Sent: Wednesday, February 06, 2008 6:20 PM
> To: Anirban Sinha; Greg Banks
> Cc: [email protected]
> Subject: RE: kernel exports table flushes out on running exportfs -a
> over mips
>
> Hi:
>
> I did some extensive digging into the codebase and I believe I have
the
> reason why exportfs -a flushes out the caches after NFS clients have
> mounted the NFS filesystem.
> The analysis is complicated, but here's
> the crux of the matter:
>
> There is a difference in the /etc/exports and the kernel maintained
> cache. The difference is that in /etc/exports, we use anonymous
clients
> (*) whereas kernel maintains a FQDN client names in its exports cache
> (see attached file). This difference (the parsing code
client_gettype()
> specifically checks for a * or an IP or hostname among other things
and
> based on that creates two different types of caches) is causing the
nfs
> codebase to recreate new in core exports entries (the second time when
> we issue "exportfs -a") after parsing /proc/fs/nfs/export. Immediately
> later, it then throws these away (for these newly created entries,
> m_mayexport = 0 and m_exported = 1 in function xtab_read()). For
> details, see the logic in exports_update_one():
>
> if (exp->m_exported && !exp->m_mayexport) { ... unexporting ...}
>
>
> Since both the anonymous and FQDN entries are essentially the same,
> this results in blowing away the existing kernel exports table.
>
> My question is, is there a elegant solution to this problem without
> simply using FQDN in /etc/exports? I have confirmed that the problem
> does not occur when both the in kernel and /etc/exports tables have
> same entries (both * or both FQDN).
>
> Cheers,
>
> Ani
>
>
> > -----Original Message-----
> > From: [email protected] [mailto:linux-nfs-
> > [email protected]] On Behalf Of Anirban Sinha
> > Sent: Thursday, January 31, 2008 2:09 PM
> > To: Greg Banks
> > Cc: [email protected]
> > Subject: RE: kernel exports table flushes out on running exportfs -a
> > over mips
> >
> > Hi Greg:
> >
> > Thanks for replying. Here goes my response:
> >
> > > -----Original Message-----
> > > From: Greg Banks [mailto:[email protected]]
> > > Sent: Wednesday, January 30, 2008 6:37 PM
> > > To: Anirban Sinha
> > > Cc: [email protected]
> > > Subject: Re: kernel exports table flushes out on running exportfs
-
> a
> > > over mips
> > >
> > > On Wed, Jan 30, 2008 at 05:34:13PM -0800, Anirban Sinha wrote:
> > > > Hi:
> > > >
> > > > I am seeing an unusual problem on running nfs server on mips.
> Over
> > > Intel
> > > > this does not happen. When I run exportfs -a on the server when
> > > > the clients have already mounted their nfs filesystem, the
kernel
> > exports
> > > > table as can be seen from /proc/fs/nfs/exports gets completely
> > > flushed
> > > > out. We (me and one another colleague) have done some digging
> > (mostly
> > > > looking into nfsutils codebase) and it looks like a kernel side
> > > issue.
> > > > We had also asked folks in the linux-mips mailing list, but
> > > apparently
> > > > no one has any clue. I am just hoping that those who are more
> > > familiar
> > > > with the user level and kernel side of nfs might me something
> more
> > to
> > > > chew on. If you can give any suggestions that will be really
> > useful.
> > > If
> > > > you think the information I provided is not enough, I can give
> you
> > > any
> > > > other information you need in this regard.
> > >
> > > Does the MIPS box have the /proc/fs/nfsd/ filesystem mounted?
> >
> > Ahh, I see what you mean. Yes, it is mounted, both /proc/fs/nfsd and
> > /proc/fs/nfs. However, I can see from the code that
check_new_cache()
> > checks for a file "filehandle" which does not exist in that
location.
> > To be dead sure, I instrumented the code to insert a perror and it
> > returns "no such file or directory". The new_cache flag remains 0.
Is
> > this some sort of kernel bug?
> >
> >
> > > Perhaps you could try
> > >
> > > 1) running exportfs under strace. I suggest
> > > strace -o /tmp/s.log -s 1024 exportfs ...
> >
> > Strace does not work in our environment as it has not been properly
> > ported to mips.
> >
> > > 2) AND enabling kernel debug messages
> > > rpcdebug -m nfsd -s export
> > > rpcdebug -m rpc -s cache
> >
> > I attach the dmesg output after enabling those flags. Zeugma-x-y are
> > the clients to this server. Not sure if it means anything
suspicious.
> >
> > Ani
> >
> >
> > >
> > >
> > > --
> > > Greg Banks, R&D Software Engineer, SGI Australian Software Group.
> > > The cake is *not* a lie.
> > > I don't speak for SGI.
Hi:
I did some extensive digging into the codebase and I believe I have the
reason why exportfs -a flushes out the caches after NFS clients have
mounted the NFS filesystem.
The analysis is complicated, but here's
the crux of the matter:
There is a difference in the /etc/exports and the kernel maintained
cache. The difference is that in /etc/exports, we use anonymous clients
(*) whereas kernel maintains a FQDN client names in its exports cache
(see attached file). This difference (the parsing code client_gettype()
specifically checks for a * or an IP or hostname among other things and
based on that creates two different types of caches) is causing the nfs
codebase to recreate new in core exports entries (the second time when
we issue "exportfs -a") after parsing /proc/fs/nfs/export. Immediately
later, it then throws these away (for these newly created entries,
m_mayexport = 0 and m_exported = 1 in function xtab_read()). For
details, see the logic in exports_update_one():
if (exp->m_exported && !exp->m_mayexport) { ... unexporting ...}
Since both the anonymous and FQDN entries are essentially the same, this
results in blowing away the existing kernel exports table.
My question is, is there a elegant solution to this problem without
simply using FQDN in /etc/exports? I have confirmed that the problem
does not occur when both the in kernel and /etc/exports tables have same
entries (both * or both FQDN).
Cheers,
Ani
Attached:
root:[email protected]:~# cat /proc/fs/nfs/exports
# Version 1.1
# Path Client(Flags) # IPs
/cf4
zeugma-1-3(rw,insecure,no_root_squash,async,wdelay,no_subtree_check,inse
cure_locks)
/cf2
zeugma-1-4(rw,insecure,no_root_squash,async,wdelay,no_subtree_check,inse
cure_locks)
/cf2/cpu3
zeugma-1-3(rw,insecure,no_root_squash,async,wdelay,no_subtree_check,inse
cure_locks)
/cf2/cpu4
zeugma-1-4(rw,insecure,no_root_squash,async,wdelay,no_subtree_check,inse
cure_locks)
/cf2/cpu2
zeugma-1-2(rw,insecure,no_root_squash,async,wdelay,no_subtree_check,inse
cure_locks)
/cf2
zeugma-1-2(rw,insecure,no_root_squash,async,wdelay,no_subtree_check,inse
cure_locks)
/cf4
zeugma-1-2(rw,insecure,no_root_squash,async,wdelay,no_subtree_check,inse
cure_locks)
/cf4
zeugma-1-4(rw,insecure,no_root_squash,async,wdelay,no_subtree_check,inse
cure_locks)
/cf2
zeugma-1-3(rw,insecure,no_root_squash,async,wdelay,no_subtree_check,inse
cure_locks)
root:[email protected]:~# cat /etc/exports
/cf2
*(rw,insecure,async,insecure_locks,no_subtree_check,no_root_squash)
/cf2/cpu2
*(rw,insecure,async,insecure_locks,no_subtree_check,no_root_squash)
/cf2/cpu3
*(rw,insecure,async,insecure_locks,no_subtree_check,no_root_squash)
/cf2/cpu4
*(rw,insecure,async,insecure_locks,no_subtree_check,no_root_squash)
/cf4
*(rw,insecure,async,insecure_locks,no_subtree_check,no_root_squash)
> -----Original Message-----
> From: [email protected] [mailto:linux-nfs-
> [email protected]] On Behalf Of Anirban Sinha
> Sent: Thursday, January 31, 2008 2:09 PM
> To: Greg Banks
> Cc: [email protected]
> Subject: RE: kernel exports table flushes out on running exportfs -a
> over mips
>
> Hi Greg:
>
> Thanks for replying. Here goes my response:
>
> > -----Original Message-----
> > From: Greg Banks [mailto:[email protected]]
> > Sent: Wednesday, January 30, 2008 6:37 PM
> > To: Anirban Sinha
> > Cc: [email protected]
> > Subject: Re: kernel exports table flushes out on running exportfs -a
> > over mips
> >
> > On Wed, Jan 30, 2008 at 05:34:13PM -0800, Anirban Sinha wrote:
> > > Hi:
> > >
> > > I am seeing an unusual problem on running nfs server on mips. Over
> > Intel
> > > this does not happen. When I run exportfs -a on the server when
> > > the clients have already mounted their nfs filesystem, the kernel
> exports
> > > table as can be seen from /proc/fs/nfs/exports gets completely
> > flushed
> > > out. We (me and one another colleague) have done some digging
> (mostly
> > > looking into nfsutils codebase) and it looks like a kernel side
> > issue.
> > > We had also asked folks in the linux-mips mailing list, but
> > apparently
> > > no one has any clue. I am just hoping that those who are more
> > familiar
> > > with the user level and kernel side of nfs might me something more
> to
> > > chew on. If you can give any suggestions that will be really
> useful.
> > If
> > > you think the information I provided is not enough, I can give you
> > any
> > > other information you need in this regard.
> >
> > Does the MIPS box have the /proc/fs/nfsd/ filesystem mounted?
>
> Ahh, I see what you mean. Yes, it is mounted, both /proc/fs/nfsd and
> /proc/fs/nfs. However, I can see from the code that check_new_cache()
> checks for a file "filehandle" which does not exist in that location.
> To be dead sure, I instrumented the code to insert a perror and it
> returns "no such file or directory". The new_cache flag remains 0. Is
> this some sort of kernel bug?
>
>
> > Perhaps you could try
> >
> > 1) running exportfs under strace. I suggest
> > strace -o /tmp/s.log -s 1024 exportfs ...
>
> Strace does not work in our environment as it has not been properly
> ported to mips.
>
> > 2) AND enabling kernel debug messages
> > rpcdebug -m nfsd -s export
> > rpcdebug -m rpc -s cache
>
> I attach the dmesg output after enabling those flags. Zeugma-x-y are
> the clients to this server. Not sure if it means anything suspicious.
>
> Ani
>
>
> >
> >
> > --
> > Greg Banks, R&D Software Engineer, SGI Australian Software Group.
> > The cake is *not* a lie.
> > I don't speak for SGI.
On Thursday January 31, ASinha-z4qIPS1Syiu/3pe1ocb+swC/[email protected] wrote:
> >
> > Does the MIPS box have the /proc/fs/nfsd/ filesystem mounted?
>
> Ahh, I see what you mean. Yes, it is mounted, both /proc/fs/nfsd and
> /proc/fs/nfs. However, I can see from the code that check_new_cache()
> checks for a file "filehandle" which does not exist in that location. To
> be dead sure, I instrumented the code to insert a perror and it returns
> "no such file or directory". The new_cache flag remains 0. Is this some
> sort of kernel bug?
OK, that means that /proc/fs/nfs is *not* mounted.
/proc is mounted, and it contains several directories including
/proc/fs/nfs and proc/fs/nfsd.
To get modern NFS service, you need to
mount -t nfsd nfsd /proc/fs/nfsd
before running any nfsd related programs (e.g. mountd, nfsd).
Most distro do that in their startup scripts. It seems you are
missing this.
However it should still work. It seems that it doesn't.
I tried without /proc/fs/nfsd mounted and got the same result as you.
It seems that we broke things when /var/lib/nfs/rmtab was changed to
store IP addresses rather than host names.
The following patch to nfs-utils will fix it. Or you can just mount
the 'nfsd' filesystem as above.
NeilBrown
diff --git a/support/export/client.c b/support/export/client.c
index 1cb242f..e96f5e0 100644
--- a/support/export/client.c
+++ b/support/export/client.c
@@ -462,5 +462,5 @@ client_gettype(char *ident)
sp++; if(!isdigit(*sp) || strtoul(sp, &sp, 10) > 255 || *sp != '.') return MCL_FQDN;
sp++; if(!isdigit(*sp) || strtoul(sp, &sp, 10) > 255 || *sp != '\0') return MCL_FQDN;
/* we lie here a bit. but technically N.N.N.N == N.N.N.N/32 :) */
- return MCL_SUBNETWORK;
+ return MCL_FQDN;
}
Hi Neil:
Thanks for responding. My response goes below:
> -----Original Message-----
> From: Neil Brown [mailto:[email protected]]
> Sent: Wednesday, February 06, 2008 9:22 PM
> To: Anirban Sinha
> Cc: Greg Banks; [email protected]
> Subject: RE: kernel exports table flushes out on running exportfs -a
> over mips
>
> On Thursday January 31, ASinha-z4qIPS1Syiu/3pe1ocb+swC/[email protected] wrote:
> > >
> > > Does the MIPS box have the /proc/fs/nfsd/ filesystem mounted?
> >
> > Ahh, I see what you mean. Yes, it is mounted, both /proc/fs/nfsd and
> > /proc/fs/nfs. However, I can see from the code that
check_new_cache()
> > checks for a file "filehandle" which does not exist in that
location.
> To
> > be dead sure, I instrumented the code to insert a perror and it
> returns
> > "no such file or directory". The new_cache flag remains 0. Is this
> some
> > sort of kernel bug?
>
> OK, that means that /proc/fs/nfs is *not* mounted.
>
> /proc is mounted, and it contains several directories including
> /proc/fs/nfs and proc/fs/nfsd.
>
> To get modern NFS service, you need to
> mount -t nfsd nfsd /proc/fs/nfsd
>
> before running any nfsd related programs (e.g. mountd, nfsd).
> Most distro do that in their startup scripts. It seems you are
> missing this.
Oh I see. I will try mounting nfsd tomorrow and check if the issue still
exists. One quick question. On analysis, I see that with new cache, the
code writes a numeric value (seconds from epoch) to <cache>/flush. It
does this for auth and nfsd caches. What does it supposed to do?
>
> However it should still work. It seems that it doesn't.
> I tried without /proc/fs/nfsd mounted and got the same result as you.
> It seems that we broke things when /var/lib/nfs/rmtab was changed to
> store IP addresses rather than host names.
>
> The following patch to nfs-utils will fix it. Or you can just mount
> the 'nfsd' filesystem as above.
If I have understood the codebase correctly, I do not see how this fixes
the problem. In our environment, since /etc/exports has "*" and proc has
client hostnames, they should end up being added in different cache
types (ANONYMOUS and FQDN respectively). What we need is to match *
with specific clients or say 0.0.0.0. You see what I mean?
Ani
>
> NeilBrown
>
>
>
> diff --git a/support/export/client.c b/support/export/client.c
> index 1cb242f..e96f5e0 100644
> --- a/support/export/client.c
> +++ b/support/export/client.c
> @@ -462,5 +462,5 @@ client_gettype(char *ident)
> sp++; if(!isdigit(*sp) || strtoul(sp, &sp, 10) > 255 || *sp !=
> '.') return MCL_FQDN;
> sp++; if(!isdigit(*sp) || strtoul(sp, &sp, 10) > 255 || *sp !=
> '\0') return MCL_FQDN;
> /* we lie here a bit. but technically N.N.N.N == N.N.N.N/32 :)
*/
> - return MCL_SUBNETWORK;
> + return MCL_FQDN;
> }
Sorry, I does look like it indeed solved the problem. Clearly, I have
missed something in my analysis of the codebase. In any case, thanks a
lot.
Good night,
Ani
> -----Original Message-----
> From: Neil Brown [mailto:[email protected]]
> Sent: Wednesday, February 06, 2008 9:22 PM
> To: Anirban Sinha
> Cc: Greg Banks; [email protected]
> Subject: RE: kernel exports table flushes out on running exportfs -a
> over mips
>
> On Thursday January 31, ASinha-z4qIPS1Syiu/3pe1ocb+swC/[email protected] wrote:
> > >
> > > Does the MIPS box have the /proc/fs/nfsd/ filesystem mounted?
> >
> > Ahh, I see what you mean. Yes, it is mounted, both /proc/fs/nfsd and
> > /proc/fs/nfs. However, I can see from the code that
check_new_cache()
> > checks for a file "filehandle" which does not exist in that
location.
> To
> > be dead sure, I instrumented the code to insert a perror and it
> returns
> > "no such file or directory". The new_cache flag remains 0. Is this
> some
> > sort of kernel bug?
>
> OK, that means that /proc/fs/nfs is *not* mounted.
>
> /proc is mounted, and it contains several directories including
> /proc/fs/nfs and proc/fs/nfsd.
>
> To get modern NFS service, you need to
> mount -t nfsd nfsd /proc/fs/nfsd
>
> before running any nfsd related programs (e.g. mountd, nfsd).
> Most distro do that in their startup scripts. It seems you are
> missing this.
>
> However it should still work. It seems that it doesn't.
> I tried without /proc/fs/nfsd mounted and got the same result as you.
> It seems that we broke things when /var/lib/nfs/rmtab was changed to
> store IP addresses rather than host names.
>
> The following patch to nfs-utils will fix it. Or you can just mount
> the 'nfsd' filesystem as above.
>
> NeilBrown
>
>
>
> diff --git a/support/export/client.c b/support/export/client.c
> index 1cb242f..e96f5e0 100644
> --- a/support/export/client.c
> +++ b/support/export/client.c
> @@ -462,5 +462,5 @@ client_gettype(char *ident)
> sp++; if(!isdigit(*sp) || strtoul(sp, &sp, 10) > 255 || *sp !=
> '.') return MCL_FQDN;
> sp++; if(!isdigit(*sp) || strtoul(sp, &sp, 10) > 255 || *sp !=
> '\0') return MCL_FQDN;
> /* we lie here a bit. but technically N.N.N.N == N.N.N.N/32 :)
*/
> - return MCL_SUBNETWORK;
> + return MCL_FQDN;
> }