Tracy R Reed wrote:
Andrew Lentvorski wrote:
You will rattle the internal disk *hard* because it will be rebuilding
he external disk regularly. It will fail much sooner than you expect.
While it can't hurt to alternate isn't a disk rebuild just reading
everything from one disk and writing it to another? Isn't that what
disks are designed to do? It should be relatively easy on the heads
because they won't have to move very much unless the server itself puts
the drives under a lot of stress during the rebuild. Shouldn't they be
able to read from one side of the disk to the other without much trouble?
In theory, yes, especially for RAID 1.
In practice, there is overhead required to store mirror status (sectors
actually mirrored vs. sectors with errors, etc.). Normally this is
written to the target drive. This would mean that every so often the
target drive has to write some status and then will resume rebuilding.
This will cause a pause and seek on the source drive.
In reality, the number of seeks will be a function of the available
memory cache of the RAID system. This means that inexpensive, pure
hardware systems will almost always rattle the source drive *hard* as
they have very little RAM cache--they will write rebuild status to disk
a lot. Expensive hardware RAID cards have their own RAM cache so can
rebuild with less load.
Software RAID systems can borrow resources of the host which generally
has a very powerful processor and huge memory compared to a RAID card.
This is one of the reasons why I'm a big fan of software
RAID--practically every reasonable RAID card gets outperformed by the
server in which it sits. This is especially true for systems with a
Southbridge connected to a Northbridge by something like DMI
(2Gigabytes/s) or Hypertransport.
The second reason to prefer software RAID is that you never have to
worry about the proprietary disk format when your RAID card/chipset
dies. Two disks running software RAID under Linux or FreeBSD are still
compatible if you pull the drives and dump them in a new server (as long
as you get the device names right).
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
