Re: Is Read speed faster when 1 disk is failed on raid5 ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Oct 29, 2002 at 01:05:59PM -0800, Yiqiang Ding wrote:
> Hi Jakob,
> 

Hello Ding,

> Thanks for your kind explanation. Sounds pretty reasonable. I also have done
> some tests on raid5 with 4k and 128k chunk size. The results are as follows:
> Access Spec     4K(MBps)        4K-deg(MBps)    128K(MBps)
> 128K-deg(MBps)
> 2K Seq Read     23.015089       33.293993       25.415035       32.669278
> 2K Seq Write    27.363041       30.555328       14.185889       16.087862
> 64K Seq Read    22.952559       44.414774       26.02711        44.036993
> 64K Seq Write   25.171833       32.67759        13.97861        15.618126

Very interesting !

> 
> Some conclusions:
> 1. "Degraded" raid5 has better (sequential) read/write performances. The
> biggest difference is in 64k sequential read, almost doubled.
> 2. Bigger chunk size makes less difference between non-degraded and degraded
> RAID5. This is due to less seek penalty for bigger chunksize raid5 according
> to Jakob's theory.
> 3. Bigger chunk size makes worse write performance. Why? Maybe somebody can
> explain this.

I'm going wild-guessing on (3) here...

It could be, that while you are writing your file, a write smaller than
your chunk size is scheduled by the VM (or something - I'm not exactly a
block/VM interaction wizard) - so a 128k parity block is written out.
Some time later, the rest of the parity block is scheduled for writing,
and the same but recalculated 128k parity block is written out once
again.

Neil, or anyone else with more kernel understanding than me, please
comment on that   :)

A work-around for this, as I see it, would be to change the RAID-5
driver so that it - during *writing* only - internally works on 512 byte
"sub-chunks" *no*matter* the actual chunk size on the array.

This does not break compatibility with existing RAIDs as I see it - no
additional information is needed in the superblock either. I think this
optimization could be done completely transparently.

I'd love to come up with a patch, but there's a zero likelihood of that
happening before the weekend.

-- 
................................................................
:   jakob@unthought.net   : And I see the elder races,         :
:.........................: putrid forms of man                :
:   Jakob Østergaard      : See him rise and claim the earth,  :
:        OZ9ABN           : his downfall is at hand.           :
:.........................:............{Konkhra}...............:
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux RAID Wiki]     [ATA RAID]     [Linux SCSI Target Infrastructure]     [Linux Block]     [Linux IDE]     [Linux SCSI]     [Linux Hams]     [Device Mapper]     [Device Mapper Cryptographics]     [Kernel]     [Linux Admin]     [Linux Net]     [GFS]     [RPM]     [git]     [Yosemite Forum]


  Powered by Linux