From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Understanding BTRFS RAID0 Performance
Date: Fri, 5 Oct 2018 10:40:14 +0000 (UTC) [thread overview]
Message-ID: <pan$77fbd$8ebaf02d$210deb71$a2b73f29@cox.net> (raw)
In-Reply-To: 54026c92-9cd1-2ac8-5747-c5405dd82087@panasas.com
Wilson, Ellis posted on Thu, 04 Oct 2018 21:33:29 +0000 as excerpted:
> Hi all,
>
> I'm attempting to understand a roughly 30% degradation in BTRFS RAID0
> for large read I/Os across six disks compared with ext4 atop mdadm
> RAID0.
>
> Specifically, I achieve performance parity with BTRFS in terms of
> single-threaded write and read, and multi-threaded write, but poor
> performance for multi-threaded read. The relative discrepancy appears
> to grow as one adds disks.
[...]
> Before I dive into the BTRFS source or try tracing in a different way, I
> wanted to see if this was a well-known artifact of BTRFS RAID0 and, even
> better, if there's any tunables available for RAID0 in BTRFS I could
> play with. The man page for mkfs.btrfs and btrfstune in the tuning
> regard seemed...sparse.
This is indeed well known for btrfs at this point, as it hasn't been
multi-read-thread optimized yet. I'm personally more familiar with the
raid1 case, where which one of the two copies gets the read is simply
even/odd-PID-based, but AFAIK raid0 isn't particularly optimized either.
The recommended workaround is (as you might expect) btrfs on top of
mdraid. In fact, while it doesn't apply to your case, btrfs raid1 on top
of mdraid0s is often recommended as an alternative to btrfs raid10, as
that gives you the best of both worlds -- the data and metadata integrity
protection of btrfs checksums and fallback (with writeback of the correct
version) to the other copy if the first copy read fails checksum
verification, with the much better optimized mdraid0 performance. So it
stands to reason that the same recommendation would apply to raid0 --
just do single-mode btrfs on mdraid0, for better performance than the as
yet unoptimized btrfs raid0.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
next prev parent reply other threads:[~2018-10-05 10:42 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-04 21:33 Understanding BTRFS RAID0 Performance Wilson, Ellis
2018-10-05 8:45 ` Nikolay Borisov
2018-10-05 10:40 ` Duncan [this message]
2018-10-05 15:29 ` Wilson, Ellis
2018-10-06 0:34 ` Duncan
2018-10-08 12:20 ` 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='pan$77fbd$8ebaf02d$210deb71$a2b73f29@cox.net' \
--to=1i5t5.duncan@cox.net \
--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 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).