public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Brian Candler <B.Candler@pobox.com>
To: Dave Chinner <david@fromorbit.com>
Cc: David Fuller <dfuller@epoch.com>, xfs@oss.sgi.com
Subject: Re: Fragmentation Issue We Are Having
Date: Fri, 13 Apr 2012 09:17:25 +0100	[thread overview]
Message-ID: <20120413081725.GA3640@nsrc.org> (raw)
In-Reply-To: <20120413075634.GD6734@dastard>

On Fri, Apr 13, 2012 at 05:56:34PM +1000, Dave Chinner wrote:
> In some cases.
> 
> You can't just blindly assert that something is needed purely on
> the size of the filesystem.

Thanks, but then perhaps the XFS FAQ needs updating. It warns that you might
have compatibility problems with old clients (NFS) and inode64, but it
doesn't say "for some workloads inode32 may perform better than inode64 on
large filesystems".

Also, aren't these orthogonal features?

(1) "I want all my inode metadata stored at the front of the disk"

(2) "I want files in the same directory to be distributed between AGs, not
    stored in the same AG"

If there are not explicit knobs for these behaviours, then it seems almost
accidental that limiting yourself to 32-bit inode numbers causes them to
happen (an implementation artefact).

Finally, what happens if you have a filesystem smaller than 1TB? I imagine
that XFS will scale the agsize down so that you have multiple AGs, but will
still have 32-bit inode numbers - so you will get the same behaviour as
inode64 on a large filesystem.  What happens then if your workload requires
behaviour (1) and/or (2) above for optimal performance?

Regards,

Brian.

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

  reply	other threads:[~2012-04-13  8:17 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-12  1:04 Fragmentation Issue We Are Having David Fuller
2012-04-12  2:16 ` Dave Chinner
2012-04-12  2:55   ` David Fuller
2012-04-12  4:24     ` Eric Sandeen
2012-04-12  7:57 ` Brian Candler
2012-04-13  0:09   ` David Fuller
2012-04-13  7:19     ` Brian Candler
2012-04-13  7:56       ` Dave Chinner
2012-04-13  8:17         ` Brian Candler [this message]
2012-04-17  0:26           ` Dave Chinner
2012-04-17  8:58             ` Brian Candler
2012-04-18  1:36               ` Dave Chinner
2012-04-18  9:00                 ` Brian Candler
2012-04-19 23:12                   ` Dave Chinner
  -- strict thread matches above, loose matches on Subject: below --
2012-04-19 19:54 Richard Scobie

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=20120413081725.GA3640@nsrc.org \
    --to=b.candler@pobox.com \
    --cc=david@fromorbit.com \
    --cc=dfuller@epoch.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