Re: [squid-users] squid with linux or freeBSD?

----- Original Message -----
From: "Brett Lymn" <blymn@baesystems.com.au>
To: "fooler" <fooler@skyinet.net>
Cc: "Colin Campbell" <sgcccdc@citec.qld.gov.au>;
<squid-users@squid-cache.org>
Sent: Thursday, May 01, 2003 1:08 PM
Subject: Re: [squid-users] squid with linux or freeBSD?

> On Thu, May 01, 2003 at 12:30:00PM +0800, fooler wrote:
> >
> >
> > > Doesn't performance actually *increase* if you lose a disk? Sure
you're
> > > "degraded" as far as redundancy goes but performance-wise you win
because
> > some
> > > percentage of reads (and writes?) no longer involves the parity
> > calculation
> > > (it's on the missing disk) and so occur faster.
> >
> > true and those parity informations available on the available disks turn
> > into data block and not parity block anymore thus your raid 5 turns into
> > raid 0 on that situation :->
> >
>
> No. Your performance degrades. You get slower and you risk losing
> your data if another disk dies. You get a lower read performance
> because the data must be reconstructed from the information on the
> disks instead of just reading the stripe and plucking the data out. I
> would _guess_ that writing would be the same since the parity is
> calculated anyway. Raid 5 does not degrade to raid 0 ... ever, the
> data striping is not done like that. You could _almost_ say that
> about RAID 3 but hardly anyone supports doing RAID 3 due to the
> drawbacks of having the parity stored on one disk.

but it is much also posible to implement that kind of technique as what i
describe above when two disks left for maximum performance right? upon
returning the third disk online, just rebuild the parity across the three
disks again... thus when two disks left, it is much better to act as raid 0
rather than still acting as raid 5 where the other strip is data block and
other strip is parity block and XOR it to get the actual data... well i
guess this is all depends on the implementor's logic regarding to raid 5
when the situation has two disks left...

fooler.
Received on Wed Apr 30 2003 - 23:40:12 MDT