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(a)ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QG,
Phone: +44 1223 334715 United Kingdom.