All of lore.kernel.org
 help / color / mirror / Atom feed
From: Erkki Seppala <flux-btrfs@inside.org>
To: linux-btrfs@vger.kernel.org
Subject: Re: BTRFS as image store for KVM?
Date: Mon, 05 Oct 2015 11:43:18 +0300	[thread overview]
Message-ID: <m498u7hd7tl.fsf@coffee.modeemi.fi> (raw)
In-Reply-To: 56111598.2080403@bouton.name

Lionel Bouton <lionel-subscription@bouton.name> writes:

> 1/ AFAIK the kernel md RAID1 code behaves the same (last time I checked
> you need 2 processes to read from 2 devices at once) and I've never seen
> anyone arguing that the current md code is unstable.

This indeed seems to be the case on my MD RAID1 HDD.

But on MD SSD RAID10 it does use all the four devices (using dd on the
md raid device and inspection iostat at the samy time).

So the lack of MD RAID1 doing it on HDDs seems to be for devices that
don't perform well in random access scenarios, as you mentioned.

In practical terms I seem to be getting about 1.1 GB/s from the 4 SSDs
with 'dd', whereas I seem to be getting ~650 MB/s when I dd from two
fastest components of the MD device at the same time. As it seems that I
get 330 M/s from two of the SSDs and 150M/s from the other two, it seems
the concurrent RAID10 IO is scaling linearly.

(In fact maybe I should look into why the two devices are getting lower
speeds overall - they used to be fast.)

I didn't calculate how large the linearly transferred chunks would need
to be to overcome the seek altency. Probably quite large.

-- 
  _____________________________________________________________________
     / __// /__ ____  __               http://www.modeemi.fi/~flux/\   \
    / /_ / // // /\ \/ /                                            \  /
   /_/  /_/ \___/ /_/\_\@modeemi.fi                                  \/


  parent reply	other threads:[~2015-10-05  8:43 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-15 21:34 BTRFS as image store for KVM? Gert Menke
2015-09-16  3:00 ` Chris Murphy
2015-09-16  3:57 ` Duncan
2015-09-16 11:35   ` Brendan Heading
2015-09-16 12:25     ` Austin S Hemmelgarn
2015-09-16 12:41     ` Paul Jones
2015-09-17 17:56   ` Gert Menke
2015-09-17 18:35     ` Chris Murphy
2015-09-17 21:32       ` Gert Menke
2015-09-18  2:00       ` Duncan
2015-09-18  8:32         ` Gert Menke
2015-09-23  7:28         ` Russell Coker
2015-09-18 14:13       ` Austin S Hemmelgarn
2015-09-23  7:24         ` Russell Coker
2015-09-17 18:46     ` Mike Fleetwood
2015-09-17 19:43     ` Hugo Mills
2015-09-17 21:49       ` Gert Menke
2015-09-18  2:22       ` Duncan
2015-09-18  8:59         ` Gert Menke
2015-09-17 22:41     ` Sean Greenslade
2015-09-18  7:34       ` Gert Menke
2015-09-17  4:19 ` Paul Harvey
2015-09-20  1:26 ` Jim Salter
2015-09-25 12:48   ` Rich Freeman
2015-09-25 12:56     ` Jim Salter
2015-09-25 13:04     ` Austin S Hemmelgarn
     [not found]       ` <5605483A.7040103@jrs-s.net>
2015-09-25 13:46         ` Austin S Hemmelgarn
2015-09-25 13:52       ` Jim Salter
2015-09-25 14:02         ` Timofey Titovets
2015-09-25 14:20           ` Austin S Hemmelgarn
2015-09-29 14:12             ` Gert Menke
2015-10-02  4:21             ` Russell Coker
2015-10-02 12:07               ` Austin S Hemmelgarn
2015-10-03  8:32                 ` Russell Coker
2015-10-04  2:09                   ` Duncan
2015-10-04 12:03                     ` Lionel Bouton
2015-10-04 12:21                       ` Rich Freeman
2015-10-05  8:19                         ` Duncan
2015-10-05  8:43                       ` Erkki Seppala [this message]
2015-10-05  8:51                         ` Roman Mamedov
2015-10-05 11:16                       ` Lionel Bouton
2015-10-05 11:40                         ` Rich Freeman
2015-10-05 11:54                         ` Austin S Hemmelgarn
     [not found]                       ` <RPG31r00t34oj7R01PG5Us>
2015-10-05 14:04                         ` Duncan
2015-10-05 15:59                           ` Austin S Hemmelgarn

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=m498u7hd7tl.fsf@coffee.modeemi.fi \
    --to=flux-btrfs@inside.org \
    --cc=linux-btrfs@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.