From: Dave Chinner <david@fromorbit.com>
To: "Łukasz Oleś" <lukasz.oles@open-e.com>
Cc: Artur Piechocki <artur.piechocki@open-e.com>, xfs@oss.sgi.com
Subject: Re: xfsprogs 2.x vs 3.x logsize changed
Date: Fri, 19 Nov 2010 12:04:21 +1100 [thread overview]
Message-ID: <20101119010421.GZ13830@dastard> (raw)
In-Reply-To: <201011171549.04806.lukasz.oles@open-e.com>
On Wed, Nov 17, 2010 at 03:49:04PM +0100, Łukasz Oleś wrote:
> Hi,
>
> I'm upgrading xfsprogs from 2.10.1 to the latest 3.1.4 version. I noticed that
> when I'm creating large lvm volume (2T) the log size is almost 1G in the old
> version it was 128M.
> I know I can manipulate this value with -lsize option, but I'm wondering why
> this difference is so huge?
Many workloads were demonstrated to have substantially better
performance with larger logs, even on small filesystems. At 4TB,
most people are using RAID of some kind, so larger logs are quite
beneficial here.
> On this volume I have one sparse file which is exported by iSCSI Target. I
> have script which calculates for me "seek" value for dd command and now it
> returns me wrong values.
> Can I stay with the old log size or maybe there are some good reasons to use
> new values?
Staying with the old log size is just fine - it'll behave exactly
the same as it does now. There are two main things hat make a larger
log size attractive:
1. log size determines maximum transaction parallelism, so
so smaller logs may limit operational concurrency. A
128MB log typically allows ~250 concurrent transactions
on a 1TB, 4k block size filesystem.
2. larger logs allow the filesystem to soak up larger burst
of metadata modifications without needing to write back
dirty metadata.
The downside ot a larger log is that recovery can take longer after
a crash.
Anyway, if you are having no problems at 128MB, then just use
that...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
prev parent reply other threads:[~2010-11-19 1:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-17 14:49 xfsprogs 2.x vs 3.x logsize changed Łukasz Oleś
2010-11-17 21:22 ` Michael Monnerie
[not found] ` <4CE41315.8070402@sandeen.net>
2010-11-18 9:49 ` Łukasz Oleś
2010-11-18 14:39 ` Eric Sandeen
2010-11-19 1:04 ` Dave Chinner [this message]
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=20101119010421.GZ13830@dastard \
--to=david@fromorbit.com \
--cc=artur.piechocki@open-e.com \
--cc=lukasz.oles@open-e.com \
--cc=xfs@oss.sgi.com \
/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