Unless the log
disk maxes out, a mirrored pair of log disks should not need to be
extended.
2 disks combined as mirrored filesystem log
| Log 1 | Log 2 |
30 disks combined as three concatenated RAID-5 arrays of 10 disks
| Array 1 | Array 1 | Array 1 | Array 1 | Array 1 | Array 1 | Array 1 | Array 1 | Array 1 | Array 1| Array 2 | Array 2 | Array 2 | Array 2 | Array 2 | Array 2 | Array 2 | Array 2 | Array 2 | Array 2 | Array 3 | Array 3 | Array 3 | Array 3 | Array 3 | Array 3 | Array 3 | Array 3 | Array 3 | Array 3 | |
The high performance number crunching choice
High throughput applications such as number crunching that want to do
large, high-speed, sequential reads and writes should use a
completely separate collection of disks on their own controllers. In
most cases, data can be regenerated if there is a disk failure, or
occasional snapshots of the data could be compressed and archived into
the home directory space. The key thing is to off-load frequent,
I/O-intensive activity from the home directories into this high performance
"scratch-pad" area.
Configure as many fast-wide (20 megabytes per second) or Ultra-SCSI (40
megabytes per second) disk controllers as you can. Each disk should be
able to stream sequential data at between 3 and 5 megabytes per
second, so don't put too many on each bus. Non-volatile memory in array
controllers may help in some cases, but it may also get in the way. The
cost may also tempt you to use too few controllers.
