Message-ID: <3CC976ED.2C947B0F@up.ac.za>
Date: Fri, 26 Apr 2002 17:49:01 +0200
From: Paul Schutte <paul@up.ac.za>
MIME-Version: 1.0
To: Thor Lancelot Simon <tls@reefedge.com>
CC: Steve Lord <lord@sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: performance patches
References: <Pine.LNX.4.44.0204260900070.26820-100000@stout.americas.sgi.com> <3CC95F9A.91A4F784@up.ac.za> <1019831421.23258.16.camel@jen.americas.sgi.com> <20020426110215.A29694@pla-muek.reefedge.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I know that it grows with the size, but the rate is much too slow.
If you create a 2Gb filesystem, you will have a 1200b log.
If you create a 64Gb filesystem, you still have the same 1200b log.
(That was still the case when a have set up my mailserver a month
ago).

If you have 80 clients logging in on a 8Gb partition as in his case,
you can be sure to have your performance limited by your
1200b log.
1200b is good for a workstation, not for a high performance server.
How was he suppose to know that.

The size of the filesystem does not matter as much as the amount
of I/O that you expect, as Steve pointed out.
Larger filesystems obviously have potential for more I/O.

Maybe I put this a bit harsh, but I am trying to defend XFS's honour.
All the people that I encountered that said XFS's performace sucks,
used the default log size.
After corrrecting their mistake, they were impressed by XFS.
I bet that we have lost a lot of people because of a too small
log size.

Paul

Thor Lancelot Simon wrote:

> On Fri, Apr 26, 2002 at 09:30:21AM -0500, Steve Lord wrote:
> >
> > If you are putting xfs on a disk and not using it for I/O intensive
> > operations, then a smaller log is all you need. There is a cost
> > associated with a larger log - longer mount times even when the
> > filesystem was cleanly unmounted.
> >
> > The default size does grow with larger filesystems, but I think they
> > need to be pretty big before that kicks in. The sizing is more an Irix
> > thing than a linux one - I think it does not kick in until 1 Tbyte.
>
> According to the Irix 6.5.13 announcement:
>
>    Improved exit codes for the xfsrestore and xfsdump commands.
>
>    Changed the mkfs command to allow you to specify the size of an XFS
>    allocation group, as an alternative to specifying the total
>    number of allocation groups.
>
>    Changed the mkfs command to allow you to specify the size of a
>    stripe unit and the size of a stripe width in bytes or in
>    filesystem blocks, as an alternative to specifying these values
>    in 512-byte block units.
>
>    Changed the default size of an XFS allocation group; larger
>    filesystems will result in larger default allocation group sizes.
>
>    The xfsdump and xfsrestore commands will provide the VSN of the
>    tape that reached its end-of-volume (or the VSN of a new tape
>    that needs to be mounted) and pass this VSN to the
>    media_change_alert_program specified with the -c option.
>
>    Changed the default size of an XFS log. The default log size
>    grows with the size of the filesystem up to the maximum log
>    size, 128 megabytes, on a 1 terabyte filesystem.
>
> Thor