linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Brown <david@westcontrol.com>
To: stan@hardwarefreak.com
Cc: keld@keldix.com, CoolCold <coolthecold@gmail.com>,
	Linux RAID <linux-raid@vger.kernel.org>
Subject: Re: XFS on top RAID10 with odd drives count and 2 near copies
Date: Tue, 14 Feb 2012 09:58:10 +0100	[thread overview]
Message-ID: <4F3A2222.8050304@westcontrol.com> (raw)
In-Reply-To: <4F39D9B2.3050305@hardwarefreak.com>

On 14/02/2012 04:49, Stan Hoeppner wrote:
> On 2/13/2012 5:02 PM, keld@keldix.com wrote:
>
>> And anyway, I think a 7 spindle raid10,f2 would be much faster
>> than a md linear array setup, both for small files and for largish
>> sequential files. But try it out and report to us what you find.
>
> The results of the target workload should be interesting, given the
> apparent 7 spindles of stripe width of mdraid10,f2, and only 3
> effective spindles with the linear array of mirror pairs, an apparent
> 4 spindle deficit.
>

If you try to make two simultaneous reads to the same "effective 
spindle", i.e., the same raid pair, won't you get simultaneous reads - 
one from each half of the mirror?  So even though XFS thinks it is 
sitting on three "disks", you'll still get much of the 6 spindle speed? 
  Certainly if the pairs are raid10,f2 then larger reads from the pairs 
will go at double speed as the data is striped in the pair.

>> I would expect  a linear md, and also most other MD raids would
>> tend to perform better in the almost empty state, as the files will
>> be placed on the faster parts of the spindles.
>
> This is not the case with XFS.
>
>> raid10,f2 would have a more uniform performance as it gets filled,
>> because read access to files would still be to the faster parts of
>> the spindles.
>
> This may be the case with EXTx, Reiser, etc, but not with XFS.
>
> XFS creates its allocation groups uniformly across the storage
> device. So assuming your filesystem contains more than a handful of
> directories, even a very young XFS will have directories and files
> stored from outer to inner tracks.
>
> This layout of AGs, and the way XFS makes use of them, is directly
> responsible for much of XFS' high performance.  For example, a
> single file create operation on a full EXTx filesystem will exhibit a
> ~30ms combined seek delay with an average 3.5" SATA disk.  With XFS
> it will be ~10ms.  This is because with EXTx the directories are at
> the outer edge and the free space is on the far inner edge.  With XFS
> the directory and free space area few tracks apart within the same
> allocation group.  Once you seek the directory in the AG, the seek
> latency from there to the track with the free space may be less than
> 1ms.  The seek distance principal here is the same for single disks
> and RAID.
>

For some workloads, the closeness of the data and the metadata will give 
you much lower latencies.  For other workloads, the difference in the 
disk speed between the inner and outer areas will be more significant, 
especially if the metadata is already cached by the system.  For 
metadata-heavy operations, having it all in one place (like with ext) 
will be more efficient.  But for operations involving multiple large 
writes, XFS split over allocation groups will help keep the 
fragmentation low, which is probably part of why it has a good 
reputation for speed when working with very large files.

There is no "one size fits all" filesystem - there are always tradeoffs. 
  That's part of the fun of Linux - you can use the standard systems, or 
you can have your favourite filesystem that you know well and use 
everywhere, or you can learn about them all and try and choose the 
absolute best for each job.

  reply	other threads:[~2012-02-14  8:58 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-10 15:17 XFS on top RAID10 with odd drives count and 2 near copies CoolCold
2012-02-11  4:05 ` Stan Hoeppner
2012-02-11 14:32   ` David Brown
2012-02-12 20:16   ` CoolCold
2012-02-13  8:50     ` David Brown
2012-02-13  9:46       ` CoolCold
2012-02-13 11:19         ` David Brown
2012-02-13 13:46       ` Stan Hoeppner
2012-02-13  8:54     ` David Brown
2012-02-13  9:49       ` CoolCold
2012-02-13 12:09     ` Stan Hoeppner
2012-02-13 12:42       ` David Brown
2012-02-13 14:46         ` Stan Hoeppner
2012-02-13 21:40       ` CoolCold
2012-02-13 23:02         ` keld
2012-02-14  3:49           ` Stan Hoeppner
2012-02-14  8:58             ` David Brown [this message]
2012-02-14 11:38             ` keld
2012-02-14 23:27               ` Stan Hoeppner
2012-02-15  8:30                 ` Robin Hill
2012-02-15 13:30                   ` Stan Hoeppner
2012-02-15 14:03                     ` Robin Hill
2012-02-15 15:40                     ` David Brown
2012-02-17 13:16                       ` Stan Hoeppner
2012-02-17 14:57                         ` David Brown
2012-02-17 19:30                           ` Peter Grandi
2012-02-18 13:59                             ` David Brown
2012-02-19 14:46                           ` Peter Grandi
2012-02-17 19:03                         ` Peter Grandi
2012-02-17 22:12                           ` Stan Hoeppner
2012-02-18 17:09                           ` Peter Grandi
2012-02-15  9:24                 ` keld
2012-02-15 12:10                 ` David Brown
2012-02-15 13:08                   ` keld
2012-02-17 18:44                 ` Peter Grandi
2012-02-18 17:39                   ` Peter Grandi
2012-02-14  7:31           ` CoolCold
2012-02-14  9:05             ` David Brown
2012-02-14 11:10               ` Stan Hoeppner
2012-02-14  2:49         ` Stan Hoeppner

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=4F3A2222.8050304@westcontrol.com \
    --to=david@westcontrol.com \
    --cc=coolthecold@gmail.com \
    --cc=keld@keldix.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=stan@hardwarefreak.com \
    /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).