From: David Brown <david.brown@hesbynett.no>
To: Wolfgang Denk <wd@denx.de>
Cc: Peter Grandi <pg@lxra2.for.sabi.co.UK>,
Linux RAID <linux-raid@vger.kernel.org>
Subject: Re: The chunk size paradox
Date: Tue, 31 Dec 2013 14:51:25 +0100 [thread overview]
Message-ID: <52C2CBDD.6040207@hesbynett.no> (raw)
In-Reply-To: <20131231000132.879A7381435@gemini.denx.de>
On 31/12/13 01:01, Wolfgang Denk wrote:
> Dear Peter,
>
> In message <21186.996.238486.690328@tree.ty.sabi.co.uk> you wrote:
>>
>> Therefore a larger chunk size increases the amount of data that
>> can be fetched on each device without waiting for the other
>> device to get to the desires angular position. It has of course
>> the advnatage that you mention, but also the advantage that
>> random IO might be improved.
>
> Hm... does it make sense to discuss any of this without considering
> the actual work load of the storage system?
>
> For example, we have some RAID 6 arrays that store mostly source code
> and the resulting object files when compiling that code. In this
> environment, we have the following distribution of file sizes:
>
> 65% are smaller than 4 kB
> 80% are smaller than 8 kB
> 90% are smaller than 16 kB
> 96% are smaller than 32 kB
> 98.4% are smaller than 64 kB
>
> It appears to me, that your argumentation is valid only for large (or
> rather huge), strictly sequential file accesses only. Random acces to
> a large number of small files like in the environment shown above will
> need pretty much different settings for optimal performance.
>
> I think we should not conceal such dependencies. There is no "one
> size fits all" solution.
>
> Just my $ 0.02.
>
> Best regards,
>
> Wolfgang Denk
>
While that's true, it would be my guess that for most large raid 6
arrays, there /are/ many large files. It takes a great many small files
to justify having raid 6 rather than raid 1, but you don't need too many
large media files.
But it's important that new options are optional - we don't want to
reduce performance for existing users, even if it is for less common usage.
next prev parent reply other threads:[~2013-12-31 13:51 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-30 18:48 The chunk size paradox Phillip Susi
2013-12-30 23:38 ` Peter Grandi
2013-12-31 0:01 ` Wolfgang Denk
2013-12-31 13:51 ` David Brown [this message]
2014-01-02 20:08 ` Phillip Susi
2014-01-02 14:49 ` joystick
2014-01-02 15:24 ` Phillip Susi
2014-01-02 15:41 ` Stan Hoeppner
2014-01-02 16:31 ` Phillip Susi
2014-01-02 18:02 ` Stan Hoeppner
2014-01-02 19:10 ` Phillip Susi
2014-01-02 22:49 ` Peter Grandi
2014-01-02 23:16 ` Stan Hoeppner
2014-01-03 1:02 ` Phillip Susi
2014-01-02 19:21 ` Joe Landman
2014-01-02 22:42 ` Stan Hoeppner
2014-01-02 22:56 ` Carsten Aulbert
2014-01-03 0:19 ` Phillip Susi
2014-01-03 1:24 ` Stan Hoeppner
2014-01-03 3:14 ` Joe Landman
2014-01-03 3:19 ` Stan Hoeppner
2014-01-03 4:24 ` Stan Hoeppner
2014-01-02 23:22 ` Peter Grandi
2014-01-03 3:09 ` Joe Landman
2014-01-03 4:58 ` Joe Landman
2014-01-02 22:32 ` Wolfgang Denk
2014-01-03 14:51 ` Benjamin ESTRABAUD
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52C2CBDD.6040207@hesbynett.no \
--to=david.brown@hesbynett.no \
--cc=linux-raid@vger.kernel.org \
--cc=pg@lxra2.for.sabi.co.UK \
--cc=wd@denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).