All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gionatan Danti <g.danti@assyoma.it>
To: Dave Chinner <david@fromorbit.com>
Cc: linux-xfs@vger.kernel.org, g.danti@assyoma.it
Subject: Re: Question about logbsize default value
Date: Fri, 25 Oct 2019 09:10:28 +0200	[thread overview]
Message-ID: <eb0ef021-27be-c0bd-5950-103cd8b04594@assyoma.it> (raw)
In-Reply-To: <20191024215027.GC4614@dread.disaster.area>

On 24/10/19 23:50, Dave Chinner wrote:
> On Wed, Oct 23, 2019 at 11:40:33AM +0200, Gionatan Danti wrote:
> 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....

Hi Dave, thank you for your explanation. The observed behavior of a 
large LSU surely matches what you described - less-than-optimal fsync perf.

That said, I was wondering why *logbsize* (rather than LSU) has a low 
default of 32k (or, better, its default is to match LSU size). If I 
understand it correctly, a large logbsize (eg: 256k) on top of a small 
LSU (32k) would give high performance on both full-log-writes and 
partial-log-writes (eg: frequent fsync).

Is my understanding correct? If you, do you suggest to always set 
logbsize to the maximum supported value?

Thanks.

-- 
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti@assyoma.it - info@assyoma.it
GPG public key ID: FF5F32A8

  reply	other threads:[~2019-10-25  7:23 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
2019-10-25  7:10   ` Gionatan Danti [this message]
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=eb0ef021-27be-c0bd-5950-103cd8b04594@assyoma.it \
    --to=g.danti@assyoma.it \
    --cc=david@fromorbit.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.