/etc/mnttab and /etc/rmtab as bottlenecks?
Richard L. Hamilton
clients using automount to mount from the server on demand.
Odds are there will be mounts and unmounts happening almost
constantly. Indeed, most of the I/O on the server's root
filesystem will be to /etc/rmtab.
Imagine a mail server (could be same as the NFS server with
the accounts on it) running sendmail for a similar number of
users. It will be mounting user directories as sendmail
checks for user's ~/.forward files, an unmounting them as
the mounts time out. There will also be heavy updating activity
on /etc/mnttab.
To make it worse, the updates to both have to be serialized.
None of the above is theoretical; heavy load on root filesystem
due to nothing other than /etc/rmtab and/or /etc/mnttab updates
has been seen, although I don't yet know how to determine what
if any impact on responsiveness or throughput that has had.
(suggestions welcome as to how to do that)
/etc/mnttab could be pushed into the kernel, which already has
almost all the information needed from the mount(2) call;
timestamps for the mount time would have to be added internally,
and most C programs could be insolated from the change by
using altered versions of getmntent(3c) and getmntany(3c), supported
by new system calls allowing system mount info to be retrieved.
(This sort of thing *is* possible; AIX (which I don't usually cite
as a desirable example) has no /etc/mnttab, but rather has calls to
get the corresponding information from the kernel.) Only those
programs which update /etc/mnttab, or read it directly, without using
the access functions, would need to be updated. The kernel
would still have to serialize access to the data structures
corresponding to mount entries, but could do so in an optimized
way that kept the bottleneck to a minimum.
Unfortunately, while information corresponding to /etc/mnttab
doesn't need to survive a crash (or power outage if we assume
that Solaris doesn't make a habit of crashing), the whole point
of /etc/rmtab is to have a record that _does_ survive a crash
of which clients have already asked and been allowed to mount
what. So that can't be pushed totally into the kernel, unless
one adds a generous hunk of NVRAM to the system. But wait; NVRAM
sort of suggests something else: a solid-state disk maybe?
So has anyone added a SCSI solid-state disk (with integral
battery and hard disk backup) or perhaps two (mirroring, if paranoid)
to a system, for use by / (and by /var, if it wasn't too big)
to such an NFS and/or mail server, because of the pounding on the
root filesystem? And if so, do they have some measure of whether
it was worth doing?
A related question: is there any particular limit to the maximum
number of mounts that the kernel, or autofs, or automountd, can
handle?
--
ftp> get |fortune
377 I/O error: smart remark generator failed
Bogonics: the primary language inside the Beltway
mailto:rlh...@mindwarp.smart.net http://www.smart.net/~rlhamil
Casper H.S. Dik - Network Security Engineer
rlh...@smart.net (Richard L. Hamilton) writes:
>Imagine an NFS server with hundreds if not thousands of
>clients using automount to mount from the server on demand.
>Odds are there will be mounts and unmounts happening almost
>constantly. Indeed, most of the I/O on the server's root
>filesystem will be to /etc/rmtab.
You could link it to /dev/null or to tmpfs.
>Imagine a mail server (could be same as the NFS server with
>the accounts on it) running sendmail for a similar number of
>users. It will be mounting user directories as sendmail
>checks for user's ~/.forward files, an unmounting them as
>the mounts time out. There will also be heavy updating activity
>on /etc/mnttab.
Increase the automount timeout; that way, directories will be
kept mounted for a long time.
(Solaris 8 will have an in-kernel mnttab; mnttab shouldn't be a problem there)
>To make it worse, the updates to both have to be serialized.
>/etc/mnttab could be pushed into the kernel, which already has
>almost all the information needed from the mount(2) call;
>timestamps for the mount time would have to be added internally,
>and most C programs could be insolated from the change by
>using altered versions of getmntent(3c) and getmntany(3c), supported
>by new system calls allowing system mount info to be retrieved.
>(This sort of thing *is* possible; AIX (which I don't usually cite
>as a desirable example) has no /etc/mnttab, but rather has calls to
>get the corresponding information from the kernel.) Only those
>programs which update /etc/mnttab, or read it directly, without using
>the access functions, would need to be updated. The kernel
>would still have to serialize access to the data structures
>corresponding to mount entries, but could do so in an optimized
>way that kept the bottleneck to a minimum.
Solaris 8 has:
mnttab /etc/mnttab mntfs dev=3400000 940852706
>Unfortunately, while information corresponding to /etc/mnttab
>doesn't need to survive a crash (or power outage if we assume
>that Solaris doesn't make a habit of crashing), the whole point
>of /etc/rmtab is to have a record that _does_ survive a crash
>of which clients have already asked and been allowed to mount
>what. So that can't be pushed totally into the kernel, unless
>one adds a generous hunk of NVRAM to the system. But wait; NVRAM
>sort of suggests something else: a solid-state disk maybe?
Well, nothing really depends in that information; it's just a
"nice to have" kinda thing; it is only used to broadcast server
shutdown message to client when the NFS server goes down.
>A related question: is there any particular limit to the maximum
>number of mounts that the kernel, or autofs, or automountd, can
>handle?
No.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.