From mboxrd@z Thu Jan 1 00:00:00 1970 From: Learner Study Subject: Re: Linux Raid performance Date: Fri, 2 Apr 2010 20:06:14 -0700 Message-ID: References: <20100331201539.GA19395@rap.rap.dk> <20100402110506.GA16294@rap.rap.dk> <4BB69670.3040303@sauce.co.nz> <4BB69BE1.5090107@sauce.co.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <4BB69BE1.5090107@sauce.co.nz> Sender: linux-raid-owner@vger.kernel.org To: Richard Scobie Cc: Mark Knecht , linux-raid@vger.kernel.org, keld@dkuug.dk, learner.study@gmail.com List-Id: linux-raid.ids Thanks to everyone for sharing their experiences...this was helpful. I don't have luxury to have 16 SAS/SATA drives...I guess it would be great if someone can share results with even higher number of disks...I would like to know what is the max performance that can be reached...I understand the theoretical is more like a couple of Terabytes...but won't we get into some sort of linux file system related or other kernel bottlenecks as we increase the # of disks? On Fri, Apr 2, 2010 at 6:37 PM, Richard Scobie wr= ote: > Mark Knecht wrote: > >> Richard, >> =A0 =A0Good point. I was limited in my thinking to the sorts of arra= ys I >> might use at home being no wider than 3, 4 or 5 disks. However for o= ur >> N-wide array as N approaches infinity so do the cycles required to r= un >> it. I don think that applies to the OP but I don't know that. >> > > I said I thought the busiest CPU was the parity generation one, but i= n > hindsight this cannot be correct, as it was almost maxed out at half = the > write speed the array achieved when it was empty. > > Regards, > > Richard > -- To unsubscribe from this list: send the line "unsubscribe linux-raid" i= n the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html