Mailing List Archive

You can run regular command from any Unix machine:
showmount [-a] <filerName>


-----Original Message-----
From: David Lee [mailto:t.d.lee@durham.ac.uk]
Sent: Friday, July 05, 2002 4:51 PM
To: toasters@mathworks.com
Subject: /etc/rmtab


From time to time, it is useful to see which NFS clients might currently
be NFS-mounting software from a NetApp server.

On a typical UNIX fileserver, the mount daemon maintains a text-format
file "/etc/rmtab" (or similar) which can quickly be browsed (or grep'ped
etc.).

I see that NetApp also has an "/etc/rmtab" file, which seems to record
similar information. But:
(a) it seems undocumented;
(b) it is not text-formatted, but seems rather to be a four-byte binary
entry-length followed by the entry itself.

Now whilst I could quickly hack together a C program or perl-script to
make this human-readable, it would seem worthwhile to ask:
(a) is "/etc/rmtab" supported?
(b) is it documented? (page number?)
(c) are there already some established and accepted ways to make its
contents human-readable?
(d) is there a FilerView (WWW) way of seeing the information in here?


--

: David Lee I.T. Service :
: Systems Programmer Computer Centre :
: University of Durham :
: http://www.dur.ac.uk/t.d.lee/ South Road :
: Durham :
: Phone: +44 191 374 2882 U.K. :

t.d.lee@durham.ac.uk (David Lee) writes
>
> From time to time, it is useful to see which NFS clients might currently
> be NFS-mounting software from a NetApp server.

And the official way to do this is to use the MOUNTPROC_DUMP remote
procedure call, which ONTAP (like almost every NFS server implementation)
supports. Usually one uses the "showmount" program for this.

> On a typical UNIX fileserver, the mount daemon maintains a text-format
> file "/etc/rmtab" (or similar) which can quickly be browsed (or grep'ped
> etc.).

/etc/rmtab is just part of the implementation used by mountd (or equivalent)
to implement MOUNTPROC_DUMP. More specifically, it provides stable storage
so that the list survives a server reboot.

Of course, it is sometimes convenient to look at it directly, but you
should appreciate that you are looking inside the covers of the black
box when you do so!

> I see that NetApp also has an "/etc/rmtab" file, which seems to record
> similar information. But:
> (a) it seems undocumented;

There's an na_rmtab(5) man page: not that it says much (but why should it?).

> (b) it is not text-formatted, but seems rather to be a four-byte binary
> entry-length followed by the entry itself.

True: it's been like that since very early ONTAP releases. Maybe NetApp
were worried about mount path names with newlines in them? Anyway, it's
their design decision.

Some other points about the format: the host part of the entry is always
an IP address (many Unix implementations use resolved host names). Entries
are deleted by overwriting the first data character with a "#", which is
entirely traditional.

> Now whilst I could quickly hack together a C program or perl-script to
> make this human-readable,

I could offer you my Perl script(s), but as the format is so simple to
unpick it hardly seems worthwhile. :)

> it would seem worthwhile to ask:
> (a) is "/etc/rmtab" supported?

I very much doubt that NetApp would want to guarantee that the format
will remain the same.

> (b) is it documented? (page number?)
> (c) are there already some established and accepted ways to make its
> contents human-readable?
> (d) is there a FilerView (WWW) way of seeing the information in here?

I think I've covered most of that, except that I don't know of a Windoze
equivalent of "showmount".

Some remarks about changes in /etc/rmtab handling in different ONTAP
releases:

. Probably in 6.0 (between 5.3.7 and 6.1, anyway) ONTAP started rewriting
clean /etc/rmtab's with all deleted entries removed whenever too many
of the latter had accumulated. Before that, this only happened at reboot
time (and so /etc/rmtab could get very large indeed).

. In 6.2, the order of entries in the cleaned-up /etc/rmtab changed
substantially, probably as a result of changes to the in-store data
structures. Before that, you could assume that the order was more or
less the order of the original mount's: this is no longer true.

The big problem with all this apparatus, regardless of implementation, is
that junk entries accumulate in the list, because clients go away without
doing a MOUNTPROC_UMNT (or ever coming back to do a MOUNTPROC_UMNTALL).
I could go on about this at some length, but this post is already long
enough! See the mid-June toasters thread "cleaning up rmtab" and back
references there.

Chris Thompson
Email: cet1@cam.ac.uk