public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Hugo Mills <hugo@carfax.org.uk>,
	Austin S Hemmelgarn <ahferroin7@gmail.com>,
	Sandy McArthur <sandymac@gmail.com>,
	Toggenburger Lukas <Lukas.Toggenburger@htwchur.ch>,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: Working on Btrfs as topic for master thesis
Date: Wed, 22 Jan 2014 13:20:10 +0100	[thread overview]
Message-ID: <20140122122010.GG6498@twin.jikos.cz> (raw)
In-Reply-To: <20140121165200.GF3314@carfax.org.uk>

On Tue, Jan 21, 2014 at 04:52:00PM +0000, Hugo Mills wrote:
> On Tue, Jan 21, 2014 at 07:25:43AM -0500, Austin S Hemmelgarn wrote:
> > > Maybe this happens already: Might a similar effect be automatically
> > > achieved by tracking per-device I/O load averages and distributing
> > > reads based on the I/O loads of possible read devices?
> > > 
> > That might be the case, it depends on how the I/O load averages are
> > calculated.  I actually hadn't realized BTRFS did this, I thought it
> > behaved more like MD RAID (that is, distributing the reads among devices
> > in a un-weighted round-robin fashion).
> 
>    I think David tried that a while ago, and the benchmarks were
> actually worse. I'm not sure how much investigation he did into why,
> though.

I haven't done any extensive testing, only streaming writes, and the
heuristic just batched writes by a given threshold before switching to
another mirror.  Load balancing was done without any logic that would
look at actual IO load of the devices. For me, the result was that
there's room for improvement.

  parent reply	other threads:[~2014-01-22 12:20 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-16 19:23 Working on Btrfs as topic for master thesis Toggenburger Lukas
2014-01-17 15:34 ` David Sterba
2014-01-17 16:04 ` Tomasz Torcz
2014-01-18 12:50   ` Toggenburger Lukas
2014-01-22 12:05     ` David Sterba
2014-01-22 13:35       ` Hugo Mills
2014-01-20  5:44 ` Roger Binns
2014-01-22 12:12   ` David Sterba
2014-01-22 20:55     ` Roger Binns
2014-01-23 18:36       ` David Sterba
2014-01-23 21:47         ` Roger Binns
2014-01-20 12:20 ` Austin S Hemmelgarn
2014-01-21  6:42   ` Sandy McArthur
2014-01-21 12:25     ` Austin S Hemmelgarn
2014-01-21 16:52       ` Hugo Mills
2014-01-21 16:59         ` Austin S Hemmelgarn
2014-01-22 12:20         ` David Sterba [this message]
2014-01-22 12:24           ` David Sterba

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=20140122122010.GG6498@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --cc=Lukas.Toggenburger@htwchur.ch \
    --cc=ahferroin7@gmail.com \
    --cc=hugo@carfax.org.uk \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=sandymac@gmail.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