Btrfs devel - Jun 2012 - Question, Does BTRFS provide a read speed increase with RAID1

Hello,
I was wondering if I setup a array via BTRFS as RAID1 will I get a
read speed increase? (multiplied by the amount of harddrives)
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On 14.06.2012 11:08, Jordan Windsor wrote:
> Hello,
> I was wondering if I setup a array via BTRFS as RAID1 will I get a
> read speed increase? (multiplied by the amount of harddrives)
Only if you read from multiple processes (or threads). Currently
the lowest-order bit of the pid is used to choose the mirror to
read from.
> Thanks.
> --
> To unsubscribe from this list: send the line "unsubscribe
linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Thu, Jun 14, 2012 at 11:10:56AM +0200, Arne Jansen
wrote:
> On 14.06.2012 11:08, Jordan Windsor wrote:
> > Hello,
> > I was wondering if I setup a array via BTRFS as RAID1 will I get a
> > read speed increase? (multiplied by the amount of harddrives)
> 
> Only if you read from multiple processes (or threads). Currently
> the lowest-order bit of the pid is used to choose the mirror to
> read from.
I''ve experimented with it once and came up with this simple change to
rotate the mirror

http://www.spinics.net/lists/linux-btrfs/msg12745.html

it does not select the mirror by pid but "rotating" on each mirror
request, but I did not bring any numbers and the implementation is not
clean (it uses a single static variable for all fses etc., but it works
for testing), so the patch fell on the floor.

Picking it up again later to get some more insight if it''s the right
heuristic I did preliminary tests on 2 disks in raid1 and modified the
rotor hint from

   rotor++ % mirrors

to

   (rotor++ >> SHIFT) % mirrors

The numbers measured on a light ''copy large file'' load showed
that the
original simple increment is awfully bad, the bandwidth used was like
15/60 MB/s .

Varying SHIFT, I recorded these numbers:
SHIFT   throughput    time
2               28    1:45
3               33    1:33
4               40    1:16
5               42    1:11
6               50    1:02
7               52    1:00
8               51    1:06
9               38    1:18

So there''s probably some achievable improvement, but in this testcase
the batched requestes per mirror are helping the (sequential) write too
much. It would need more testing on more disks, other types of loads
etc. And iirc as you noted on IRC back then, this mirror selection
should be adapted according to disk head position or connected to the
readahead framework (sorry if I''m not writing exactly as you put it).

In current implementation, a pathological case, when all the processes
get the same "pid % 2", would lead to an unused mirror, but
it''s highly
improbable (note that it''s not pid of the user process doing the read,
but the btrfs worker threads).

I''d like to find a better mirror selection hint that would work well on
avearage and will get back to it someday, unless somebody else wants to
continue experimenting here.


david
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

> I''d like to find a better mirror selection hint that would work
well on
> avearage and will get back to it someday, unless somebody else wants to
> continue experimenting here.
Well, for some context you can see what the existing kernel raid 
implementations do:

	drivers/md/raid1.c:read_balance()
	drivers/md/dm-raid1.c:do_reads()

- z
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html