Disk partitioning and swap

[ccb at kukla.tiac.net (Charles C. Bennett, Jr.)]

When I first started installing BSD 4.2c systems in preparation for
work on the ULTRIX installation procedures, BSD wanted to partition
the large DEC disks - RM03, RM05, RP06, RA80, RA60 and RA81 as
eight partitions in a scheme like this:

       /dev/ra0a:	/	    smallish - maybe 16 MB in those days
       /dev/ra0b:	swap	    usually 1.5 - 2.5X physical RAM
				    VAX RAM was in the 4 - 16MB range
       /dev/ra0c:	-	    this was a synonym for the whole disk,
				    "ra0" if you will

       /dev/ra0g:	/usr	    often as much as 150 to 200 MB
       /dev/ra0h:	/usr/users  whatever was left, on some disks this
				    was bigger than the g partition


Paritions d, e and f were an alternate breakup of g+h on the smaller
disks and an alternate breakup of h on the larger ones.  The partition
scheme was managed in a file called /etc/disktab.  I think
customizable partition tables at the front of the disk were an
innovation that came just a little later.

ULTRIX retained this partition layout almost verbatim and a similar
scheme was adopted in OSF/1 and later Digital UNIX.

When Sun and Digital were preparing to do "diskless" workstations in
1986, we got together and brainstormed about how to do the right
thing.  One of the decisions was to create a /var filesystems.  We
then did a fairly painful restructuring to get the logs, spools and
admin files out of /usr and move all of the admin *binaries* out of
/etc.  Any of the files that remained in the root filesystem were
there only because they were needed to get the machine on the air.
The main reason for pulling all writable files off of /usr was allow
it to be mounted read-only via NFS for all of the diskless clients at
a particular site.  So if you needed to allocate storage at the server
for diskless clients, you gave each client a / and /var but shared
/usr among them.  At that time Sun adopted the /home convention for
home directories while Digital retained /usr/users.

To this day, I tend to break up filesystems using the root-swap-usr
pattern, superstitiously beleiving that putting swap between them will
improve swap performance.

In recent days I too have been pondering the new user disk partition
problem.  There have been a couple of newspaper articles that point to
that as a major showstopper for the people that know they have a disk
but that's all they know about it.  What I'd like to see for these
people is a single parition laid out like this:

/apps			    ;; like "Program Files"
  /applix
  /wp8
  /soffice
  ...
/home
  /tux			    ;; default non-priv user, id 1001.1001
  ...
/linux			    ;; get it out of their face
  /root
  /bin
  /boot
  /dev
  /etc
  /lib
  /proc
  /sbin
  /tmp
  /usr
    ...
  /var
    /.swapfile		    ;; swap on the filesystem, slow but unobtrusive
    ...
/.lost+found		    ;; hide these puppies
/disk			    ;; removable media, w/automount on insertion
  /cdrom		    ;;  using synchronous mounts
  /zip
  /jaz
  /syjet
  /a:			    ;; the floppy drives
  /b:
  /c:			    ;; their Windows partitions
  /d:
  ...


A top level ls would look like this:

apps	    home	linux       disk


The top level directory would be set drwxrwxrwt, owner root.root.

A system installed this way would come up in runlevel 4, with an
X server on the console and a copy of GNOME or KDE running under
the id tux.tux with cwd of /home/tux.  No login.  An advanced user
would have the option of configuring for runlevel5 at startup and
establishing user accounts.  Run Level 4 would be configured to
operate the machine as a client - no major networking daemons would
be operating and no server admin headaches.

Now back to Jerry's questions...

Swapping to the filesystem is more expensive than swapping to a
partition but I've done it from time to time in a pinch and it was
file.  My perception is that the difference between file swap and
partition swap is not as great as the difference between swapping to
an IDE drive and swapping to a SCSI disk.

In my experience the extended partition vs. primary partition thing
is largely a matter of taste.  When it's only Linux on the box I
put things on 1, 2 and 3 and then turn 4 into an extended partition.
I believe you can only have one extended on the disk.  When it's
an NT/Linux dual boot box, I do whatever NT is comfortable with -
Linux can cope with NT's demands a lot better than the other way
around.

For question 2 - the only reason I use the second scenario for all
of my stuff is that I tend to track every release of Red Hat (soon
to end, I'm preparing the jump to Debian).  I use:

p1:	/	      96 MB
p2:	swap	      128 MB
p3:	/usr	      1000 MB
p4:		      the rest
  p5:	swap	      128 MB
  p6:	/usr/local    the rest of the rest


All of my home dirs are in /usr/local/home.  All of my stuff that's
mine is under /usr/local, including regular backups of /etc and /var.
When I do an update, I take /usr/local off line.  When I'm done I
bring it back in and fish all of my configuration info out of
/usr/local/etc and /usr/local/var.

As you can see from the layout I swap in both primary and extended
partitions.  I hadn't even imagined that there's be a performance
difference between the two.  I was laboring under the hallucination
that all the partition table does is tell the kernel what the block
offsets are for the partitions and everything is straight-out
addressing from there?  Could I be wrong?

Well... according to drivers/block/genhd.c, there's a little
additional setup work at boot time to get the block offsets and
runlengths of the logical partitions, but once they've been dug out,
access for all partition data is O(1) and access times to any region
on the disk is determined only by hardware.

ccb


---
Charles C. Bennett, Jr.				Workgroup Technology Corp.
Principal Software Engineer,			91 Hartwell Ave.
Distributed Object Computing			Lexington, MA 02421

"Talking about music is like tap dancing about architecture" - Laurie Anderson
-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).