From: Dave Chinner <david@fromorbit.com>
To: Gionatan Danti <g.danti@assyoma.it>
Cc: linux-xfs@vger.kernel.org
Subject: Re: Question about logbsize default value
Date: Fri, 25 Oct 2019 08:50:27 +1100 [thread overview]
Message-ID: <20191024215027.GC4614@dread.disaster.area> (raw)
In-Reply-To: <00242d70-1d8e-231d-7ba0-1594412714ad@assyoma.it>
On Wed, Oct 23, 2019 at 11:40:33AM +0200, Gionatan Danti wrote:
> Hi list,
> on both the mount man page and the doc here [1] I read that when the
> underlying RAID stripe unit is bigger than 256k, the log buffer size
> (logbsize) will be set at 32k by default.
>
> As in my tests (on top of software RAID 10 with 512k chunks) it seems that
> using logbsize=256k helps in metadata-heavy workload, I wonder why the
> default is to set such a small log buffer size.
>
> For example, given the following array:
>
> md126 : active raid10 sda1[3] sdb1[1] sdc1[0] sdd1[2]
> 268439552 blocks super 1.2 512K chunks 2 near-copies [4/4] [UUUU]
> bitmap: 1/3 pages [4KB], 65536KB chunk
>
> running "fs_mark -n 1000000 -k -S 0 -D 1000 -N 1000 -s 16384 -d
> /mnt/xfs/" shows the following results:
>
> 32k logbsize (default, due to 512k chunk size): 3027.4 files/sec
> 256k logbsize (manually specified during mount): 4768.4 files/sec
>
> I would naively think that logbsize=256k would be a better default. Am I
> missing something?
Defaults are for best compatibility and general behaviour, not
best performance. A log stripe unit of 32kB allows the user to
configure a logbsize appropriate for their workload, as it supports
logbsize of 32kB, 64kB, 128kB and 256kB. If we chose 256kB as the
default log stripe unit, then you have no opportunity to set the
logbsize appropriately for your workload.
remember, LSU determines how much padding is added to every non-full
log write - 32kB pads out ot 32kB, 256kB pads out to 256kB. Hence if
you have a workload that frequnetly writes non-full iclogs (e.g.
regular fsyncs) then a small LSU results in much better performance
as there is less padding that needs to be initialised and the IOs
are much smaller.
Hence for the general case (i.e. what the defaults are aimed at), a
small LSU is a much better choice. you can still use a large
logbsize mount option and it will perform identically to a large LSU
filesystem on full iclog workloads (like the above fsmark workload
that doesn't use fsync). However, a small LSU is likely to perform
better over a wider range of workloads and storage than a large LSU,
and so small LSU is a better choice for the default....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2019-10-24 21:50 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-23 9:40 Question about logbsize default value Gionatan Danti
2019-10-24 21:50 ` Dave Chinner [this message]
2019-10-25 7:10 ` Gionatan Danti
2019-10-25 23:39 ` Dave Chinner
2019-10-26 9:54 ` Gionatan Danti
2019-10-26 21:59 ` Dave Chinner
2019-10-27 18:09 ` Gionatan Danti
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=20191024215027.GC4614@dread.disaster.area \
--to=david@fromorbit.com \
--cc=g.danti@assyoma.it \
--cc=linux-xfs@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