SLUG Mailing List Archives
Re: [SLUG] Partition advice
- To: Peter Rundle <prundle@xxxxxxxxxxxxxx>
- Subject: Re: [SLUG] Partition advice
- From: Glen Turner <glen.turner@xxxxxxxxxxxxx>
- Date: Fri, 06 May 2005 02:05:09 +0930
- Cc: slug@xxxxxxxxxxx
- Organization: Australia's Academic & Research Network
- User-agent: Mozilla Thunderbird 1.0.2-1.3.2 (X11/20050324)
Peter Rundle wrote:
If you had a new scsi based server at your disposal :-) and were looking
at how to partition it up before installing a
flavour of Linux, what would you do? Ok, so a bit of a how long is a bit
of string Q, some more info.
System has hardware raid with six drives. Two 36Gb and four 72Gb. Idea
is to mirror two 36's as the system disk
and the other 4 in a raid 5 for data. System will be a bit of a jack of
all trades but primarily a Postgres database server
with a large amount of data of which relatively small amounts will be
served out using Apache and Php. Could also
end up being a mail server, and samba server maybe with a couple of
dozen user accounts.
There are three competing issues:
1) Robustness gained from partitions preventing uncontrolled
file growth. Argues for lots of small partitions.
2) System administration overhead when partitions need to be
resized. Argues for big partitions.
3) Application data access paths.
The seemingly opposed (1) and (2) criteria are slowly being addressed
by logical volumes. So they are well worth setting up.
For (3) your server is simply doing too much to give good advice.
For example, the usual recommendation for a generic database is:
- transaction journal onto mirrored disk (as this gets
hammered and RAID5 performance sucks)
- data on RAID5
- index on RAID5
The data and index are separated to limit disk head movement.
So you could look at the Postgres disk access paths and modify
this generic advice.
Similar disk access path considerations apply to Apache. You
usually put /var/log on a differing disk than /srv/www as
Apache wants to write a log record after each file read.
You don't want those two activities fighting for the disk.
Note that the current trend is that application data goes
into /srv (see the Linux Standard Base website). So that's
the screamingly obvious candidate for the RAID5 diskset.
You also need to consider your backup strategy. A tape
drives disks to saturation. You don't want that if
you're running a customer-loaded DB at the same time.
A common tactic is to add a disk to mirror the database,
which takes many hours of rate-limited disk-to-disk copying.
Once the mirror is complete, a 'backup checkpoint' is run
on the DB and the mirror broken. You've now got a coherent
snapshot of the DB on a drive which isn't in use. Send that
sucker to tape. I'm not sure if Postgres supports this, nor
what your backup strategy is. Worthwhile thinking about in case
you really want three RAIDed disk rather than four.
Also, what's the acceptable degraded performance? You
can simulate a downed disk by dropping it from the
SCSI driver. See if the DB slows to a crawl. If
it does, and that matters to you, you might want to
consider having an idle 'hot spare' disk.
Finally, a hack. Leave a partition at the start
of the boot disk big enough to install FreeDOS or your Linux
distribution's network installer. It's really handy to boot
from that when you need to update the BIOS or upgrade the
For example, for BIOS updates you can have FreeDOS, the
BIOS updater, and an AUTOEXEC.BAT file which updates the
BIOS and reboots. You can mount the FreeDOS partition
under Linux and set all that up whilst the machine is
running. Then reboot, select FreeDOS in GRUB. BIOS updates,
box reboots into Linux, total outage is a few minutes.