Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!cs.utexas.edu!rutgers!usc!bbn!mit-eddie!minya!jc
From: jc@minya.UUCP (John Chambers)
Newsgroups: comp.unix.wizards
Subject: Re: NFS and UFS Mounting on a non-empty directory
Keywords: Frustration, Yellow Pages
Message-ID: <3@minya.UUCP>
Date: 4 Aug 89 03:16:12 GMT
Distribution: na
Organization: home
Lines: 56

> Our (4.3BSD) man page for mount(2) says the following:
> >DESCRIPTION
> >     mount attaches a file system to a directory.  After a suc-
> >     cessful return, references to directory dir will refer to
> >     the root directory on the newly mounted file system.  Dir is
> >     a pointer to a null-terminated string containing a path
> >     name.  Dir must exist already, and must be a directory.  Its
>                                                                ^^^
> >     old contents are inaccessible while the file system is
>       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >     mounted.
>       ^^^^^^^

Unfortunately, this isn't quite true.  It neglects to mention that any
files in the directory that were opened before the mount will stay open
and usable by the process(es) until they are closed (or the process(es)
die(s)).  This may sound like a bit of pickiness, but in fact you can
use it to produce an interesting and amusing denial-of-services puzzle
to entertain your Unix-wizard friends.  What you do is arrange for a
program to be started before the mount that creates a file in /tmp,
then slowly adds to the file.  You can fill up the file system, and
the file is invisible to everyone but you.  Running du will show that
all the directories in the filesystem don't nearly account for all the
space, but there's no free space left.

This isn't all that marvelous a trick, of course, since you can do the
same thing without any mounts, by creating the file, unlinking it, and
then filling it up.  But it's still pretty good for stumping neophytes
who have pretensions to wizardhood.

I've seen it happen "innocently", when the file in question was an audit
trail produced by some daemon, and a mount was done after the daemon was
started.  For instance, I've seen the yp directory put into /usr/etc/yp,
when /usr/etc was a mounted partition.  The yp servers got started before
the mount, so they wrote to the "real" /usr/etc/yp, which became hidden
when the mount occurred.  But with debugging enabled, the daemons slowly
added to their hidden audit trails, filled up the /usr partition, and
nobody could figure out why it was full.  A bit of detective work in 
single-user mode solved the problem, since the mounts didn't happen then.
It also explained why the daemons seemed to be ignoring the command to
write their debug output.  To paraphrase Stephen Hawking, they did write
their output; they just wrote it where it couldn't be seen.

(Hmmm...that suggests another interesting cosmological approach:  The
reason that we can't see the "hidden variables" below the level of the
quarks is that a quark is actually a virtual object that is "mounted"
over the lower-level structure in the memory of the cosmic computer
that is running the simulation that we call "the universe", thus hiding 
the details from access from above.   Ooops; this is unix-wizards, not 
sci.farout-physics; excuse me!  ;-)

-- 
#echo 'Opinions Copyright 1989 by John Chambers; for licensing information contact:'
echo '	John Chambers <{adelie,ima,mit-eddie}!minya!{jc,root}> (617/484-6393)'
echo ''
saying