[conspire] Parititioning revisited briefly
rick at linuxmafia.com
Fri Oct 15 18:33:20 PDT 2010
If you're bored from hearing about partitioning, you're out of luck,
because I had in mind to post tidbits about it until I run out of
inspiration. Here's that server partition scheme, again:
# <file system> <mount point> <type> <options> <dump> <pass>
## sda is (obviously) the boot drive. 73 GB SCSI.
/dev/sda1 /boot ext2 defaults 0 2
/dev/sda5 none swap sw 0 0
/dev/sda6 /var ext2 noatime,nodev,nosuid 0 2
/dev/sda7 / ext3 defaults,errors=remount-ro 0 1
/dev/sda8 /recovery ext3 defaults 0 2
/dev/sda9 /usr ext2 nodev,ro 0 2
## sdb and sdc are RAID1 mirrored, except for swap. Each is 18 GB SCSI.
/dev/md0 /var/www ext3 nodev,nosuid 0 2 #sdb5,sdc5
/dev/md1 /var/lib ext3 nodev 0 2 #sdb6,sdc6
/dev/md2 /var/spool ext3 defaults 0 2 #sdb7,sdc7
/dev/sdb8 none swap sw 0 0
/dev/sdc8 none swap sw 0 0
/dev/md3 /home ext3 defaults 0 2 #sdb9,sbc9
/dev/md4 /usr/local ext3 defaults 0 2 #sdb10,sdc10
This time, a few words about choice of filesystem type, mount flags and
such. Let's start with /var.
First thing to note about /var is that I've carefully moved _off_ of the
/var partition per se all the subtrees that contain indispensible
/var/www System HTML and ftp trees
/var/lib all data files for Mailman, MySQL, some others
/var/spool System SMTP spools, NNTP spools, SpamAssassin files
Everything that remains is system-built dynamic files that come and go,
that you could blow away and would have minimal trouble from doing so.
_Therefore_, the first thing is that we want flat-out maximal
performance even at the expense of data protection, and there's nothing
better for that than good old ext2 (with no journal).
You'll notice that /boot is likewise ext2. I got into this habit during
the long period of reliance on the lilo bootloader. One distinctive
thing about lilo is that the installed bootloader, at startup time, finds
the system map, boot kernel, initial RAMdisk, and root filesystem first
sector by memorising their physical location (cylinder, head, sector,
etc.), _not_ by memorising their pathspecs within filesystems.
Therefore, lilo doesn't need to mount anything to do booting, and in
fact doesn't need to understand filesystems at all (to do booting).
Thus, when using lilo as one's bootloader, you actually almost never
need to mount /boot at all. The only time you need to mount that
subtree is when _updating_ lilo data, e.g., because you just installed a
Leaving /boot normally unmounted is yet another small protection against
mishap. Critical files in a subtree you haven't mounted are critical
files you cannot accidentally screw up.
And since you only ever mounted /boot a few times a year for fifteen
minutes at a time to implement new boot kernels, why waste space on a
filesystem journal? Thus, ext2.
As mentioned, given the reduced rationale for having a separate /boot
in the first place, I will be losing that filesystem in the future.
There are some restrictive flags on several filesystems, as a limited
sort of security measure:
The 'noatime' flag gives a filesystem a very non-trivial performance
gain, where you can get away with it, by eschewing the overhead of
continually updating the atime timestamp every time the file is
accessed _including just for reads_. ('File', here, includes
directories.) Some software relies on the atime timestamp, and
disabling it (as above ) is consider a non-standards-compliant mode
of operation. However, if no software requires atime for a subtree,
the gains are compelling.
(Note: As of kernel version 2.6.30, Linux's default behaviour is
something called 'relatime' = relative atime, invented by Valerie
Aurora, that greatly reduces atime overhead without software problems.
See: http://valhenson.livejournal.com/36519.html )
/var's nodev and nosuid are very modest security measures of a sort.
That is, given that there's no conceivable legitimate purpose for
special device files (such as /dev/sda) within /var, why permit them to
be valid there? Thus, nodev. Given that there's no conceivable
legitimate purpose for SUID files within /var, why permit them to
be valid there? Thus, nosuid.
A not-especially-sophisticated attack tool, say, a network worm, that
you or one of your users accidentally executed on your system, might be
foiled by an unexpected inability to have a special device file or a
SUID executable, functional within /var. An astute human attacker with
root authority, or a sophisticated attack tool with root authority,
would easily defeat that safeguard by remounting /var without the flag,
so it's a modest measure.
The other three filesystems' similar flags are of the same sort.
Note that one must be careful not to shoot legitimate software in the
foot, in planning these flags. Notice, for example, that /var/lib lacks
the 'nosuid' mount flag. Doubtless, this is because I tried that and
noticed something that broke. (Oops.) But it's difficult to know until
More information about the conspire