From: Josef Bacik <jbacik@fusionio.com>
To: Martin Steigerwald <Martin@lichtvoll.de>
Cc: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
Josef Bacik <JBacik@fusionio.com>,
Mitch Harder <mitch.harder@sabayonlinux.org>
Subject: Re: Varying Leafsize and Nodesize in Btrfs
Date: Thu, 30 Aug 2012 17:50:08 -0400 [thread overview]
Message-ID: <20120830215008.GB2879@localhost.localdomain> (raw)
In-Reply-To: <201208302334.49399.Martin@lichtvoll.de>
On Thu, Aug 30, 2012 at 03:34:49PM -0600, Martin Steigerwald wrote:
> Am Donnerstag, 30. August 2012 schrieb Josef Bacik:
> > On Thu, Aug 30, 2012 at 09:18:07AM -0600, Mitch Harder wrote:
> > > I've been trying out different leafsize/nodesize settings by
> > > benchmarking some typical operations.
> > >
> > > These changes had more impact than I expected. Using a
> > > leafsize/nodesize of either 8192 or 16384 provided a noticeable
> > > improvement in my limited testing.
> > >
> > > These results are similar to some that Chris Mason has already
> > > reported: https://oss.oracle.com/~mason/blocksizes/
> > >
> > > I noticed that metadata allocation was more efficient with bigger
> > > block sizes. My data was git kernel sources, which will utilize
> > > btrfs' inlining. This may have tilted the scales.
> > >
> > > Read operations seemed to benefit the most. Write operations seemed
> > > to get punished when the leafsize/nodesize was increased to 64K.
> > >
> > > Are there any known downsides to using a leafsize/nodesize bigger
> > > than the default 4096?
> >
> > Once you cross some hardware dependant threshold (usually past 32k) you
> > start incurring high memmove() overhead in most workloads. Like all
> > benchmarking its good to test your workload and see what works best,
> > but 16k should generally be the best option. Thanks,
>
> I wanted to ask about 32k either.
>
> I used 32k on one 2,5 inch external esata disk. But I never measured
> anything so far.
>
> I wonder what a good value for SSD might be. I tend to not use anymore
> than 16k, but thats just some gut feeling right now. Nothing based on a
> well-founded explaination.
>
32k really starts to depend on your workload. Generally speaking everybody will
be faster with 16k, but 32k starts to depend on your workload and hardware, and
then anything about 64k really starts to hurt with memmove(). With this sort of
thing SSD vs not isn't going to make much of a difference, erase blocks tend to
be several megs in size so you aren't going to get anywhere close to avoiding
the internal RMW cycle inside the ssd. Thanks,
Josef
next prev parent reply other threads:[~2012-08-30 21:50 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-30 15:18 Varying Leafsize and Nodesize in Btrfs Mitch Harder
2012-08-30 16:25 ` Josef Bacik
2012-08-30 21:34 ` Martin Steigerwald
2012-08-30 21:50 ` Josef Bacik [this message]
2012-08-31 0:01 ` Chris Mason
2012-08-31 5:02 ` Roman Mamedov
2012-10-11 17:58 ` Phillip Susi
2012-10-12 10:32 ` Martin Steigerwald
2012-10-12 12:52 ` Martin Steigerwald
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=20120830215008.GB2879@localhost.localdomain \
--to=jbacik@fusionio.com \
--cc=Martin@lichtvoll.de \
--cc=linux-btrfs@vger.kernel.org \
--cc=mitch.harder@sabayonlinux.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).