swap on RAID (Re: Disk Recovery suggestions welcomed...)

Rich Braun richb at pioneer.ci.net
Fri Dec 16 13:16:00 EST 2005


dsr at tao.merseine.nu seems to recommend *against* swap on RAID1:
> With two swap partitions, you have twice the amount of swap as
> if you RAID-mirrored it, and Linux knows how to alternate
> requests from each partition, so there's even a performance
> advantage.

But in RAID1, Linux knows how to read the first sector that comes up (of the
mirrored pair), so you reduce rotational latency with RAID1 (at least on the
reads, not on the writes).  It wouldn't surprise me if the RAID1 configuration
gives *lower* latency (better performance) than the striped non-RAID
configuration you're talking about.

> Odds are good that if you have a disaster that takes out a swap
> partition, you want to be rebooting immediately anyway...

Depends on your application.  If the server is supporting an office or
development site, you'll want to defer rebooting until after peak hours.  If
the server is running a 24/7 commerce application, you'll want to keep it
running without stopping.  Motherboard IDE controllers won't cut it in that
case, because they don't support hot-swap properly, but you can get
inexpensive external IDE or SCSI controllers that can do hot-swap.  And Linux
RAID1 easily resyncs without rebooting.  So you can build an inexpensive 24/7
server that never needs rebooting if you choose the tools and hardware
carefully.

But yeah, for the typical home computer, you'll probably find yourself
tinkering with the system and rebooting it soon after a drive failure.

I have two Linux systems at home, both with RAID1 partitions.  I'll confess
that on one system I have swap on the RAID partition, and on the other it's on
a regular partition.  It's nice to know that if I get a drive-failure alert on
the first system, I don't have to rush into a reboot/recovery procedure--it
can wait until after dinner or errands or whatever.  And I'm thinking maybe I
should reconfigure the second system.

-rich




More information about the Discuss mailing list