All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Łukasz Oleś" <lukasz.oles@open-e.com>
To: xfs@oss.sgi.com
Cc: Eric Sandeen <sandeen@sandeen.net>
Subject: Re: xfsprogs 2.x vs 3.x logsize changed
Date: Thu, 18 Nov 2010 10:49:41 +0100	[thread overview]
Message-ID: <201011181049.42048.lukasz.oles@open-e.com> (raw)
In-Reply-To: <4CE41315.8070402@sandeen.net>

On Wednesday 17 of November 2010 18:38:29 Eric Sandeen wrote:
> On 11/17/10 8:49 AM, Ł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?
> > 
> > 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?
> > 
> > Regards,
> > Łukasz Oleś
> 
> commit a6634fba3dec4a92f0a2c4e30c80b634c0576ad5
> Author: David Chinner <dgc@sgi.com>
> Date:   Sun May 10 21:31:22 2009 +0200
> 
>     mkfs: allow to make larger logs
> 
>     Increase the maximum log size supported by mkfs.
> 
>     The log size can be increased easily in mkfs by changing a few
>     defines and a couple of types to allow the log size to increase to
>     just under 2GB. Theoretically, the log size can be made much, much
>     larger than this (up to 2^32 sectors), but going beyond 2^31
>     *bytes* causes integer overflow issues in the kernel log code.
> 
>     We use a maximum size of just under 2GB as exactly 2GB will cause
>     overflow issues on the first transaction reservation.
> 
>     Maximum log size is now reached at a fs size of ~4TB.
> 
>     Signed-off-by: Dave Chinner <dgc@sgi.com>
>     Signed-off-by: Christoph Hellwig <hch@lst.de>
> 
> 
> did:
> 
> @@ -1737,10 +1737,10 @@ _("size %s specified for log subvolume is too
> large, maximum is %lld blocks\n"), logblocks = 0;
>         } else if (loginternal && !logsize) {
>                 /*
> -                * logblocks grows from min_logblocks to XFS_MAX_LOG_BLOCKS
> -                * at 128GB
> -                *
> -                * 2048 = 128GB / MAX_LOG_BYTES
> +                * With a 2GB max log size, default to maximum size
> +                * at 4TB. This keeps the same ratio from the older
> +                * max log size of 128M at 256GB fs size. IOWs,
> +                * the ratio of fs size to log size is 2048:1.
>                  */
>                 logblocks = (dblocks << blocklog) / 2048;
>                 logblocks = logblocks >> blocklog;
> 
> old MAX was:
> 
> -#define XFS_MAX_LOG_BYTES      (128 * 1024 * 1024)
> 
> In your case ... I'm not sure a larger log is going to help, I think
> keeping it smaller is fine if you wish.
> 
> Dave may have a different opinion though :)
> 
> -Eric

Ok, so it's this commit http://git.kernel.org/?p=fs/xfs/xfsprogs-
dev.git;a=commitdiff;h=a6634fba3dec4a92f0a2c4e30c80b634c0576ad5

Would it be safe if I just revert this commit?  It looks safe for me, but 
maybe other things depends on it and I will break something.

Regards,
Łukasz Oleś

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  parent reply	other threads:[~2010-11-18  9:46 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ś [this message]
2010-11-18 14:39     ` Eric Sandeen
2010-11-19  1:04 ` Dave Chinner

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=201011181049.42048.lukasz.oles@open-e.com \
    --to=lukasz.oles@open-e.com \
    --cc=sandeen@sandeen.net \
    --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 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.