I wrote
[...]
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 ... :)
My best fit to the observations is that a new clean /etc/rmtab is written when the proportion of non-cancelled entries in the old one falls to 10.5%. [The critical proportion is definitely more than 1/10 and definitely less than 1/9.]
The problem that obsolete entries not explicitly cancelled by client action never go away definitely still exists, though.
Indeed, it seems that in some ways it may be worse. One used to be able to sneakily cancel dross by writing judicious "#"s to /etc/rmtab oneself, and after the next reboot they would be gone. Now such trickery is lost each time a new /etc/rmtab is created from (presumably) the in-store active list.
The na_rmtab(5) man page in 6.1R1 still says that /etc/rmtab "may be removed before rebooting the server" to get rid of such things, but I wonder whether it now has to be *just* before rebooting, in case the file should reappear!
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.