From owner-freebsd-hackers  Tue May 13 10:21:17 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id KAA00670
          for hackers-outgoing; Tue, 13 May 1997 10:21:17 -0700 (PDT)
Received: from seagull.rtd.com (seagull.rtd.com [198.102.68.2])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA00665
          for <freebsd-hackers@freefall.FreeBSD.org>; Tue, 13 May 1997 10:21:14 -0700 (PDT)
Received: (from dgy@localhost) by seagull.rtd.com (8.7.5/8.7.3) id KAA15767 for freebsd-hackers@freefall.cdrom.com; Tue, 13 May 1997 10:21:13 -0700 (MST)
From: Don Yuniskis <dgy@rtd.com>
Message-Id: <199705131721.KAA15767@seagull.rtd.com>
Subject: partitions and things that go bump in the night
To: freebsd-hackers@freefall.FreeBSD.org (FreeBSD hackers)
Date: Tue, 13 May 1997 10:21:13 -0700 (MST)
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Greetings!
     Once again, I'm screwing around with reorganizing my systems.
Effectively, I have a single 340M IDE drive (internal) and 0 - 4
4G SCSI drives *external*.  I'd like to set up a "basic" system
on the IDE drive on each machine and, depending on which of
the external drives are present, build upon that.  Having a nice
"robust" fallback on the IDE is also comforting if/when some gremlin
attacks the SCSI-based filesystems.
     Of course, it would also be nice if the IDE based system was
more than a "token" system (i.e. was *useful*!)

     So, my first thinking on partitions is a small /, a small /var
and the bulk of the drive dedicated to a /usr.  Hopefully, having
a separate /var will limit the extent to which it can grow
(log files, crash dumps, etc.) and impinge upon the rest of the system.
The tiny / is intended as the "last chance" fallback -- hopefully
it is static enough that it would survive any gremlins that might
creep in and, perhaps, allow me to repair any of the other
file systems which might be damaged.
     Now, one machine likes to serve up news; likewise for mail.
Presumably, I could just mount a larger SCSI based /var filesystem
ON TOP OF the existing IDE /var directory.  (Yes, I know I could
mount at /var/mail instead, etc. and leave the balance of /var
on the IDE drive).  I *think* this is preferable to a symlink from
/var to, for example /SCSI/xyz (assuming /SCSI/xyz is somewhere on the
SCSI drives).  A symlink will choke when something tries to access
/var/mail, /var/log, etc. and the drive is not mounted.
     I've previously done this with /usr residing on the SCSI drives
but get annoyed at the fact that /usr/bin, /usr/sbin are not available
when I dismount the SCSI devices.  Mounting just /usr/local on the
SCSI drives doesn't help accomodate other things added to /usr.
So, I think overlaying /usr *completely* with the external device
is also a win.

     Now, have I set myself up for any "gotchas" down the road?
In particular, are there any files which might be opened in the
*normal* boot sequence in the IDE /var or /usr hierarchies
*before* the /var and /usr SCSI mounts occur?  How could/would
that affect me (i.e. when the opened file is suddenly obscured)?
Aside from "wasting" the overlaid parts of the IDE drive, are there
any other drawbacks to this type of approach??
     Thanks!
--don