classiccmp server hard drive info

From: Rob O'Donnell <>
Date: Mon Oct 4 04:50:20 2004

At 09:34 04/10/2004, Fred N. van Kempen wrote:

>On Mon, 4 Oct 2004, I wrote:
> > (The only problem, as with any RAID, is when you have to swap a drive and
> > need to get a new one to match - I have found even the same model of drive
> > from the same manufacturer, purchased at different times can report
> > different capacities!)
>This is not true. Especially with decent SCSI or SATA based controllers,
>one only needs to match the "surviving" drive(s) with a drive of AT LEAST
>the same capacity. If you have a RAID5 set of four 4.3GB drives, and
>drive #2 dies, you *can* without problems replace it with a 9.1G drive,
>and the array will be back up. The new drive will only have 4.3G of
>it used. This was actually a normal procedure to replace old drives
>with new drives in production arrays.. just replace them one at a
>Controllers that require identical drives in any RAID set are not worth
>the consideration in a (semi-)critical environment, as identical
>replacements are not a given.

I was perhaps unclear; certainly using a larger capacity drive is no
problem (except perhaps an irritation about the wasted space).

What I was particularly worried about was I recently replaced a drive (in
an IDE RAID 1 mirror) for one of an identical model number, and it was
reported as being several Mb larger than the surviving drive.

It has certainly been my experience that a "XX Gb drive" of one model is
unlikely to be the exact same size (in terms of number of cylinders) as a
"XX Gb drive" of a different model, even from the same
manufacturer. However if you can't trust drives of the same model numbers
to match, then the world is definitely moving downhill..

At least the new drive wasn't smaller.. then I would have been somewhat
more irritated!

>In Jay's case, I'd recomment implementing a SATA-based RAID1 set
>with two SATA 160G drives- possibly with a third one as offline
>or online (if the controller supports it) spare.


Received on Mon Oct 04 2004 - 04:50:20 BST

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:37:20 BST