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.