linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.


  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).