Re: Time to deprecate old RAID formats?

[Doug Ledford <dledford@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1932 bytes --]

On Fri, 2007-10-19 at 12:45 -0400, Justin Piszcz wrote:
> 
> On Fri, 19 Oct 2007, John Stoffel wrote:
> 
> >>>>>> "Justin" == Justin Piszcz <jpiszcz@lucidpixels.com> writes:
> >
> > Justin> Is a bitmap created by default with 1.x?  I remember seeing
> > Justin> reports of 15-30% performance degradation using a bitmap on a
> > Justin> RAID5 with 1.x.
> >
> > Not according to the mdadm man page.  I'd probably give up that
> > performance if it meant that re-syncing an array went much faster
> > after a crash.
> >
> > I certainly use it on my RAID1 setup on my home machine.
> >
> > John
> >
> 
> The performance AFTER a crash yes, but in general usage I remember seeing 
> someone here doing benchmarks it had a negative affect on performance. 

I'm sure an internal bitmap would.  On RAID1 arrays, reads/writes are
never split up by a chunk size for stripes.  A 2mb read is a single
read, where as on a raid4/5/6 array, a 2mb read will end up hitting a
series of stripes across all disks.  That means that on raid1 arrays,
total disk seeks < total reads/writes, where as on a raid4/5/6, total
disk seeks is usually > total reads/writes.  That in turn implies that
in a raid1 setup, disk seek time is important to performance, but not
necessarily paramount.  For raid456, disk seek time is paramount because
of how many more seeks that format uses.  When you then use an internal
bitmap, you are adding writes to every member of the raid456 array,
which adds more seeks.  The same is true for raid1, but since raid1
doesn't have the same level of dependency on seek rates that raid456
has, it doesn't show the same performance hit that raid456 does.

> 
> Justin.
-- 
Doug Ledford <dledford@redhat.com>
              GPG KeyID: CFBFF194
              http://people.redhat.com/dledford

Infiniband specific RPMs available at
              http://people.redhat.com/dledford/Infiniband

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]