The command 'exportfs' on the filer itself, will also display the currently exported volumes.
-----Original Message----- From: Lance A. Brown [mailto:brown9@niehs.nih.gov] Sent: Tuesday, June 12, 2001 10:17 AM To: toasters@mathworks.com Subject: Re: showmount?
Greetings,
Paul Lupa paul.lupa@motorola.com kindly reminded that
showmount -a filername
from a UNIX host will display the information I am after.
--[Lance]
{Top-posting reversed]
Lance A. Brown brown9@niehs.nih.gov wrote:
[...]
Paul Lupa paul.lupa@motorola.com kindly reminded that
showmount -a filername
from a UNIX host will display the information I am after.
The command 'exportfs' on the filer itself, will also display the currently exported volumes.
But that, of course, gives equivalent information only to "showmount -e". For the other (and more usual) options of showmount, you need to do it from a remote machine: and these are the ones to which Adam Fox's warning specifically applies.
On NFS systems of any sort, /etc/rmtab is notorious for accumulating junk entries for long-gone hosts and directories, as it has no sort of corrective process to cause it to reconverge on reality.
Hmmm... I was just about to comment on the way that /etc/rmtab grows without limit (full of deleted entries) between reboots on NetApp filers... but I've just noticed that this doesn't happen any longer in 6.1R1 (maybe earlier 6.x as well)!
Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QG, Phone: +44 1223 334715 United Kingdom.
On Tue, Jun 12, 2001 at 07:42:54PM +0100, Chris Thompson wrote:
Hmmm... I was just about to comment on the way that /etc/rmtab grows without limit (full of deleted entries) between reboots on NetApp filers... but I've just noticed that this doesn't happen any longer in 6.1R1 (maybe earlier 6.x as well)!
Really? I thought data in /etc/rmtab was supposed to stick around since NFS mounts can exist across reboots. It would be great of ONTAP had some cleanup mechanism for known bad entries (exports that have since been deleted, etc.), but I'd be curious what the exact behavior that Chris is seeing in 6.x+ is.
-- Jeff
jkrueger@qualcomm.com (Jeffrey Krueger) writes:
On Tue, Jun 12, 2001 at 07:42:54PM +0100, Chris Thompson wrote:
Hmmm... I was just about to comment on the way that /etc/rmtab grows without limit (full of deleted entries) between reboots on NetApp filers... but I've just noticed that this doesn't happen any longer in 6.1R1 (maybe earlier 6.x as well)!
Really? I thought data in /etc/rmtab was supposed to stick around since NFS mounts can exist across reboots. It would be great of ONTAP had some cleanup mechanism for known bad entries (exports that have since been deleted, etc.), but I'd be curious what the exact behavior that Chris is seeing in 6.x+ is.
You misunderstand me: the entries that need to be preserved (if you believe in this whole mechanism) don't go away, only the deleted ones.
/etc/rmtab internal formats differ between operating systems, but they usually have the properties that entries are variable length, new ones are always appended at the end, that entries are deleted (when a client does UMNT or UMNTALL) by overwriting the entry with a cancellation mark, and that removal of the deleted entries happens only on a restart of the NFS server code.
ONTAP's format (this doesn't seem to have changed in 6.x) is that the entries are:
4-byte binary length (big-endian) in bytes of following data; IP address as dotted quad in ASCII, followed by ":", followed by mount point path (e.g. "192.168.0.42:/home/foobar").
Deletion is indicated by overwriting the first byte after the length with an ASCII "#".
In an environment making heavy use of automounting, /etc/rmtab could get quite big. We used to regularly see it at 30-40 MB after a few weeks without a reboot, with 99.9% of the entries marked deleted.
It seems that in 6.x the process of compacting /etc/rmtab by removing the cancelled entries is done much more often. I deduce this from the snapshots of it that show the inode number changing, and the size going down as well as up. I haven't got enough data points yet to determine whether the compaction is done at constant intervals, or when rmtab goes over a particular size, or %-wise too full of cancelled entries, or whatever. I'm keeping an eye on it now and will find out in due course ... :)
The problem that obsolete entries not explicitly cancelled by client action never go away definitely still exists, though.
Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QG, Phone: +44 1223 334715 United Kingdom.
-
Chris Thompson -
Jeffrey Krueger -
Mohler, Jeff