Yet another RAID Question (YARQ)

Ted Mittelstaedt tedm at
Thu Jun 23 06:37:26 GMT 2005

>-----Original Message-----
>From: owner-freebsd-questions at
>[mailto:owner-freebsd-questions at]On Behalf Of Sandy
>Sent: Wednesday, June 22, 2005 3:09 AM
>To: Ted Mittelstaedt
>Cc: freebsd-questions at; Alex Zbyslaw
>Subject: RE: Yet another RAID Question (YARQ)
>>>>>> On Wed, 22 Jun 2005 01:00:09 -0700,
>>>>>> "Ted Mittelstaedt" <tedm at> said:
> > With a RAID-1 card, mirroring, there are 2 ways to setup reads.
> > The first way makes the assumption that you are mirroring purely
> > for fault tolerance.  In that case you would NOT see a ANY read from
> > the second disk.  The reason is that every time you read you move the
> > heads, and the more head movement the quicker the disk wears out.
>OK.  I wasn't aware that some RAID cards allow you to tune reads in
>this way.  Mine, which is a Mylex DAC1100, does not.

I was speaking from more of a designers theoretical standpoint rather
than a
users.  From a practical standpoint I would think that the marketing
of any RAID card manufacturer would throw up their hands in horror if a
engineer suggested doing it this way - the marketing people would say
the buyers of the card would think it was broken if they didn't see
lights on all the disk drives all the time. :-)

You see many otherwise good designs fucked up this way by marketing
people. :-(

> > Placing exactly the same amount of head movement on both disks
> > means that if you setup a mirror with new disks of the same model,
> > which is pretty much how most people do it, the MTBF on both disks
> > is the same, and if you put equal activity on both disks your making
> > a very good chance that they will fail at the same time, or
>very close
> > to the same time.
>This assumes a small standard deviation --- much smaller than I would
>think is reasonable.  I don't think that I have ever seen standard
>deviation data quoted by a manufacturer, which of course makes any MTBF
>data that they provide worthless.

Ah, but you see your working with the definition of MTBF that I used, and
that the general public uses, NOT the definition of MTBF that
Seagate uses.  (or the other disk manufacturers)

Seagate wrote a paper on this titled:

"Seagate Technology Paper 338.1 Estimating Drive Reliability in
Desktop Computers and Consumer Electronic Systems"

that explains how they define MTBF.  Basically, they define MTBF as
what percentage of disks will fail in the FIRST year.

What they are saying is if you purchase 160 Cheetahs and run them at
100% duty cycle for 1 year then there is 100% chance that 1 out of the
160 will fail.

Thus, if you only purchase 80 disks and run them at 100% duty cycle for 1
year, then you only have a 50% chance that 1 will fail.  And so on.

Ain't statistics grand?  You can make them say anything!  For an encore
Seagate went on to prove that their CEO would live 3 centuries
by statistical grouping. :-)

So, in getting back to the gist of what I was saying, the issue is
as you mentioned standard deviation.  I think we all understand that
in a disk drive assembly line that it's all robotic, and that there
is an extremely high chance that disk drives that are within a few
serial numbers of each other are going to have virtually identical
characteristics.  In fact I would say using the Seagate MTBF definition,
that 1 in every 160 drives manufactured in a particular run is going
to have a significant enough deviation to fail at a significantly
period of time, given identical workload.

In short you have better than 99% chance that if you install 2 brand
new Cheetahs that are from the same production run, they will have
virtually identical characteristics.  And, failure due to wear is going
to be
very similar - there's only so many times the disk head can seek
before it's bearings are worn out - and your proposing to give them
the exact same usage.

The interesting thing about this is that as quoted MTBF goes up, the
closer and closer to identical all your disk drives have to be.  So
the funny thing is that in a RAID-1 array, your better off with cheapo
Barracutas which have much greater deviation between each drive, than
the more expensive Cheetahs that have less deviation between each drive.

>I agree with all of this.  However, I do indeed see alternate
>flickering and the RAID array is sitting right in front of me.  I
>expect this has to do with how the intensity of the activity lights is
>tied to seek vs read.  If it matters, the drives are Cheetahs and they
>are in a Sun Multipack hot swap box.

I think the reason your seeing alternation is that the disks are
so damn fast that they complete their reads well before their internal
buffers have finished emptying themselves over the SCSI bus to the
array card.  In other words, you wasted your money on your fast disks,
if you had used slower disks you would see identical read performance
but you would see less alternative flickering
and more simultaneous and continuous activity.

If you got a faster array card you wouldn't see the alternative

Or, it could be the PCI bus not being fast enough for the array card.

>Anyway, this is all minutia...

Now, don't lessen it.  Disk drives are damn expensive espically the
fast ones.  It's a worthwhile discussion.  Besides we can all laugh at

>I think that it is fair to say that the main point of this thread is
>that if the behaviour of the drives' activity lights is not consistent
>with your RAID setup, then you should investigate --- regardless of
>what your RAID admin tool is saying.  Would you agree with this?

I actually wonder these days if the disk drive activity lights really
mean anything.

How fast is the maximum turn on/turn off time of an LED?  How fast is
the average seek/read?  How long must a light be present before the
human eye registers it?

It would not surprise me in the least if the disk manufacturers put
circuitry in the light driver that adds an extra half second to the
length of time that the light is on, merely so the human eye can
register that it has in fact, turned on.

Ah well, a computer just wouldn't be a computer without blinking
lights on it!!! ;-)


More information about the freebsd-questions mailing list