NFS4 showmount -a equivalent
ChrisS
command on an NFS4 server, what command or file does keep track of
NFS4 client mount points?
thanks
Chris
Richard B. Gilbert
more /etc/dfs/sharetab
Martin Paul
> ChrisS wrote:
>> Since NFS4 client mount points don't show up in the old showmount -a
>> command on an NFS4 server, what command or file does keep track of
>> NFS4 client mount points?
>
That might be an equivalent to "showmount -e" (show shared file systems)
but not "showmount -a" (show remote mounts).
I'd be interested on how to see which clients have mounted which
filesystem with NFSv4 as well. I did some searching in the past, and it
seems as if there's no way. "dfmounts" doesn't work either, the pointer
at "/var/nfs/v4_state/" is pretty useless as well.
The -v option to mountd, which logs every NFS mount to syslog, doesn't
work with NFSv4 either.
Is nobody interested in this information, or how else could this
deficiency slip into the production release?
mp.
--
SysAdmin | Institute of Scientific Computing, University of Vienna
PCA | Analyze, download and install patches for Solaris
| http://www.par.univie.ac.at/solaris/pca/
Tim Bradshaw
> The -v option to mountd, which logs every NFS mount to syslog, doesn't
> work with NFSv4 either.
>
The critical thing here is that there is no distinct NFSv4 mount
protocol, unlike with earlier NFS releases. So mountd is just never
invoked for NFSv4 mounts.
I don't understand NFSv4 well enough, but it is possible that there is
no real notion of mounting in the protocol at all. I think a client
just asks for a root filehandle from which it can then traverse the
server's filesystems.
It's possibly worth pointing out that showmount never actually worked
reliably because it relies on the server & client keeping state with
each other. Who hasn't run showmount and found all sorts of clients
there which not only are off but have been sold?
Peter Bunclark
Indeed, but you can clear out /etc/rmtab manually (under controlled
conditions) and then it starts being valid again. Knowing what clients
have mounted a disk is an essential part of administering a server.
Don't get me started on Solaris NVSv4 crossmounts from Linux...
Pete.
Tim Bradshaw
> Indeed, but you can clear out /etc/rmtab manually (under controlled
> conditions) and then it starts being valid again.
I don't think it starts being valid again: it goes from (normally) far
too many machines, to none, and that is no more right. Clients won't
suddenly make mount requests to update the state on the server, since
they have no reason to, as they already have the filehandle.
> Knowing what clients
> have mounted a disk is an essential part of administering a server.
Yes, and it's an awkward fact that that information has never really
been available for NFS. The best way of getting good information is
to map over the clients asking them.
Peter Bunclark
> On Apr 1, 12:43 pm, Peter Bunclark <p...@ast.cam.ac.uk> wrote:
>
>> Indeed, but you can clear out /etc/rmtab manually (under controlled
>> conditions) and then it starts being valid again.
>
> I don't think it starts being valid again: it goes from (normally) far
> too many machines, to none, and that is no more right. Clients won't
> suddenly make mount requests to update the state on the server, since
> they have no reason to, as they already have the filehandle.
The "controlled conditions" include manually identifying machines no
longer in existence, or currently shut down, and replacing the first
character with '#'. Just after a power cut is a good time. Scan the
remaining clients to see who really has a disk mounted, do some more
editing. Then either restart nfs server or reboot. Then - it starts
being valid again.
>
>> Knowing what clients
>> have mounted a disk is an essential part of administering a server.
>
> Yes, and it's an awkward fact that that information has never really
> been available for NFS. The best way of getting good information is
> to map over the clients asking them.
An RFE?
Pete.
Tim Bradshaw
> The "controlled conditions" include manually identifying machines no
> longer in existence, or currently shut down, and replacing the first
> character with '#'. Just after a power cut is a good time. Scan the
> remaining clients to see who really has a disk mounted, do some more
> editing. Then either restart nfs server or reboot. Then - it starts
> being valid again.
Agreed. However, I think that it is still often easier to achieve
this by ignoring rmtab and asking the clients, who really know (albeit
it is much slower of course).
>
> An RFE?
Well, maybe. It's not clear to me what a mount even means in NFS (any
version): how do you know when a client to whom you've handed a root
filehandle has unmounted the FS? One approach (which works for SMB I
think) would be to associate the mount with some preexisting session,
such as a TCP session, and say that when that session goes away then
the mount is done. But that is pretty hostile to clients if your
server might ever want to reboot. I think to make this work you'd
have to revisit Unix filesystem semantics in a pretty major way.
--tim
Michael Weis
Tim Bradshaw wrote at 02.04.2008 11:31
>> An RFE?
>
> Well, maybe. It's not clear to me what a mount even means in NFS (any
> version): how do you know when a client to whom you've handed a root
> filehandle has unmounted the FS? One approach (which works for SMB I
> think) would be to associate the mount with some preexisting session,
> such as a TCP session, and say that when that session goes away then
> the mount is done. But that is pretty hostile to clients if your
> server might ever want to reboot. I think to make this work you'd
> have to revisit Unix filesystem semantics in a pretty major way.
I think there is an existing RFE.
To partially solve thios behaviour I use:
# netstat -an | grep 2049 --> shows which connections to NFSv4 clients
you have, not the mounts
a DTrace script called get_nfs_clients.d, must be active when clients
use NFSv4, cannot be used for static information (ok, the name of the
underlying architecture is _Dynamic_ Tracing...) Look for the script at
www.brendangregg.com or opensolaris.org/os/community/dtrace
Michael
Martin Paul
> Agreed. However, I think that it is still often easier to achieve
> this by ignoring rmtab and asking the clients, who really know (albeit
> it is much slower of course).
Call me pedantic, but to keep rmtab info up-to-date I even have a
jumpstart finish script which mounts/unmounts the filesystems which are
used during jumpstart, and which don't get unmounted cleanly at the
reboot after install.
The problem with asking the clients is that e.g. "ssh client df -Fnfs"
might cause new NFS mounts if e.g. home directories or directories in
PATH are NFS mounted.
Martin.
Martin Paul
> # netstat -an | grep 2049 --> shows which connections to NFSv4 clients
> you have, not the mounts
Indeed, a connection shows up when a filesystem is mounted, and goes
away when it's unmounted. So it doesn't seem as if NFSv4 is stateless in
that respect (I wasn't sure about that), and therefore a command which
shows the state should exist.
Martin.
Tim Bradshaw
>
> Indeed, a connection shows up when a filesystem is mounted, and goes
> away when it's unmounted. So it doesn't seem as if NFSv4 is stateless in
> that respect (I wasn't sure about that), and therefore a command which
> shows the state should exist.
That's just incidental, unfortunately: NFSv4 generally is run over
TCP, but it does not have to be as it's just using RPC. Even when it
*is* run over TCP, I am not sure there is anything preventing a client
(or in fact the server) from harvesting TCP streams if the mount is
idle for a long time.
All of these things provide good hints as to whether there are active
mounts, of course, but they are only hints.
Tim Bradshaw
>
> The problem with asking the clients is that e.g. "ssh client df -Fnfs"
> might cause new NFS mounts if e.g. home directories or directories in
> PATH are NFS mounted.
Good point. I think what is really needed is an RPC server on the
client which will answer the question. But then there are probably
huge security questions around that (let alone it not existing at
present). When such a thing is created I insist it should be called
the TNUOM protocol.
Peter Bunclark
I don't understand why the information in
/var/nfs/v4_state/
isn't what we want - just needs a human-readable output filter?
Pete.
Tim Bradshaw
>
> I don't understand why the information in
> /var/nfs/v4_state/
> isn't what we want - just needs a human-readable output filter?
It may be that will be as good as showmount was. My point was really
that showmount was never very good (and really could not be very good)
because of the way NFS works.
Or in other words I'm wandering off into some kind of academic-CS one-
bit-mind never-never land where I get to point out that you can't
actually get what you want, instead of giving the useful answer that
it is in fact very often possible to get almost what you want and that
may be good enough.
Andrew Gabriel
Tim Bradshaw <tfb+g...@tfeb.org> writes:
>
> That's just incidental, unfortunately: NFSv4 generally is run over
> TCP, but it does not have to be as it's just using RPC.
AFAIK, it's always run over TCP. Sun doesn't support it over UDP.
--
Andrew Gabriel
[email address is not usable -- followup in the newsgroup]
Andrew Gabriel
The main problem with showmount was that some people believed
what it said.
Peter Bunclark
> In article <0ed675ad-9dc6-4d62...@s8g2000prg.googlegroups.com>,
> Tim Bradshaw <tfb+g...@tfeb.org> writes:
>> On Apr 2, 4:37 pm, Peter Bunclark <p...@ast.cam.ac.uk> wrote:
>>
>>> I don't understand why the information in
>>> /var/nfs/v4_state/
>>> isn't what we want - just needs a human-readable output filter?
>> It may be that will be as good as showmount was. My point was really
>> that showmount was never very good (and really could not be very good)
>> because of the way NFS works.
>>
>
> The main problem with showmount was that some people believed
> what it said.
>
whereas the content of /var/nfs/v4_state gets refreshed on service
restart (and clearly reboot) so does not suffer the stale entries of
rmtab/showmount. It's just that you can't directly interpret it.
Pete.