Re: raid1 inefficient unbalanced filesystem reads

From: Hugo Mills <hugo@carfax.org.uk>
To: Josef Bacik <jbacik@fusionio.com>
Cc: Martin <m_btrfs@ml1.co.uk>, linux-btrfs@vger.kernel.org
Subject: Re: raid1 inefficient unbalanced filesystem reads
Date: Fri, 28 Jun 2013 16:39:10 +0100	[thread overview]
Message-ID: <20130628153910.GM14601@carfax.org.uk> (raw)
In-Reply-To: <20130628153418.GW4288@localhost.localdomain>

[-- Attachment #1: Type: text/plain, Size: 1464 bytes --]

On Fri, Jun 28, 2013 at 11:34:18AM -0400, Josef Bacik wrote:
> On Fri, Jun 28, 2013 at 02:59:45PM +0100, Martin wrote:
> > On kernel 3.8.13:
> > 
> > Using two equal performance SATAII HDDs, formatted for btrfs raid1 for
> > both data and metadata and:
> > 
> > The second disk appears to suffer about x8 the read activity of the
> > first disk. This causes the second disk to quickly get maxed out whilst
> > the first disk remains almost idle.
> > 
> > Total writes to the two disks is equal.
> > 
> > This is noticeable for example when running "emerge --sync" or running
> > compiles on Gentoo.
> > 
> > 
> > Is this a known feature/problem or worth looking/checking further?
> 
> So we balance based on pids, so if you have one process that's doing a lot of
> work it will tend to be stuck on one disk, which is why you are seeing that kind
> of imbalance.  Thanks,

   The other scenario is if the sequence of processes executed to do
each compilation step happens to be an even number, then the
heavy-duty file-reading parts will always hit the same parity of PID
number. If each tool has, say, a small wrapper around it, then the
wrappers will all run as (say) odd PIDs, and the tools themselves will
run as even pids...

   Hugo.

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
  --- Startle, startle, little twink.  How I wonder what you think. ---  

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]