Re: Optimize RAID0 for max IOPS?

From: CoolCold <coolthecold@gmail.com>
To: Wolfgang Denk <wd@denx.de>
Cc: stefan.huebner@stud.tu-ilmenau.de, linux-raid@vger.kernel.org
Subject: Re: Optimize RAID0 for max IOPS?
Date: Mon, 24 Jan 2011 17:40:08 +0300	[thread overview]
Message-ID: <AANLkTikx4g99-Cf_09kEGfF2mmf4Dnuh2A5gTrtKweDy@mail.gmail.com> (raw)
In-Reply-To: <20110119192104.1FA92D30267@gemini.denx.de>

On Wed, Jan 19, 2011 at 10:21 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear =?ISO-8859-15?Q?Stefan_/*St0fF*/_H=FCbner?=,
>
> In message <4D361F26.3060507@stud.tu-ilmenau.de> you wrote:
>>
>> [in German:] Schätzelein, Dein Problem sind die Platten, nicht der
>> Controller.
>>
>> [in English:] Dude, the disks are your bottleneck.
> ...
>
> Maybe we can stop speculations about what might be the cause of the
> problems in some setup I do NOT intend to use, and rather discuss the
> questions I asked.
>
>> > I will have 4 x 1 TB disks for this setup.
>> >
>> > The plan is to build a RAID0 from the 4 devices, create a physical
>> > volume and a volume group on the resulting /dev/md?, then create 2 or
>> > 3 logical volumes that will be used as XFS file systems.
>
> Clarrification: I'll run /dev/md* on the raw disks, without any
> partitions on them.
>
>> > My goal is to optimize for maximum number of I/O operations per
>> > second. ...
>> >
>> > Is this a reasonable approach for such a task?
>> >
>> > Should I do anything different to acchive maximum performance?
>> >
>> > What are the tunables in this setup?  [It seems the usual recipies are
>> > more oriented in maximizing the data troughput for large, mostly
>> > sequential accesses - I figure that things like increasing read-ahead
>> > etc. will not help me much here?]
>
> So can anybody help answering these questions:
>
> - are there any special options when creating the RAID0 to make it
>  perform faster for such a use case?
> - are there other tunables, any special MD / LVM / file system /
>  read ahead / buffer cache / ... parameters to look for?
XFS is known for it's slow speed on metadata operations like updating
file attributes/removing files..but things gonna change after 2.6.35
where delaylog is used. Citating Dave Chinner :
< dchinner> Indeed, the biggest concurrency limitation has
traditionally been the transaction commit/journalling code, but that's
a lot more scalable now with delayed logging....

So, you may need to benchmark fs part.

>
> Thanks.
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
> Boykottiert Microsoft - Kauft Eure Fenster bei OBI!
> --
> 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
>

-- 
Best regards,
[COOLCOLD-RIPN]
--
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