| To: | CoolCold <coolthecold@xxxxxxxxx> |
|---|---|
| Subject: | Re: Optimize RAID0 for max IOPS? |
| From: | Justin Piszcz <jpiszcz@xxxxxxxxxxxxxxx> |
| Date: | Mon, 24 Jan 2011 10:25:02 -0500 (EST) |
| Cc: | Wolfgang Denk <wd@xxxxxxx>, stefan.huebner@xxxxxxxxxxxxxxxxxx, linux-raid@xxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx |
| In-reply-to: | <AANLkTikx4g99-Cf_09kEGfF2mmf4Dnuh2A5gTrtKweDy@xxxxxxxxxxxxxx> |
| References: | <20110118210112.D13A236C@xxxxxxxxxxxxxx> <4D361F26.3060507@xxxxxxxxxxxxxxxxxx> <20110119192104.1FA92D30267@xxxxxxxxxxxxxx> <AANLkTikx4g99-Cf_09kEGfF2mmf4Dnuh2A5gTrtKweDy@xxxxxxxxxxxxxx> |
| User-agent: | Alpine 2.00 (DEB 1167 2008-08-23) |
On Mon, 24 Jan 2011, CoolCold wrote: 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. Some info on XFS benchmark with delaylog here: http://comments.gmane.org/gmane.comp.file-systems.xfs.general/34379 Justin. |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [PATCH 5/5] xfs: handle CIl transaction commit failures correctly, Christoph Hellwig |
|---|---|
| Next by Date: | Re: Optimize RAID0 for max IOPS?, Wolfgang Denk |
| Previous by Thread: | Virus intercepted, MAILER-DAEMON |
| Next by Thread: | Re: Optimize RAID0 for max IOPS?, Wolfgang Denk |
| Indexes: | [Date] [Thread] [Top] [All Lists] |