From: Dave Chinner <david@fromorbit.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: "Cédric Lemarchand" <cedric.lemarchand@ixblue.com>, xfs@oss.sgi.com
Subject: Re: Any way to slow down fragmentation ?
Date: Thu, 15 Oct 2015 08:34:53 +1100 [thread overview]
Message-ID: <20151014213453.GP31326@dastard> (raw)
In-Reply-To: <561EA0C0.8040305@sandeen.net>
On Wed, Oct 14, 2015 at 01:36:48PM -0500, Eric Sandeen wrote:
>
>
> On 10/14/15 1:29 PM, Cédric Lemarchand wrote:
> > Well .. it seems I missed the most important part of the FAQ, thank
> > for pointing it. As you stated, playing with xfs_bmap shows that the
> > 13TB file is fragmented a lot, xfs_fsr is now working on it.
>
> how much was "a lot?"
>
> a 13TB file can have "a lot" of *very* large extents.
With the maximum extent size being 8GB, a file that large going to
see "a lot" of extents even if it isn't fragmented. It will be
spread out over multiple AGs (being 1TB max in size), and that makes
it *appear* worse than it really is. Indeed, the best case is that
the BMBT will have ~1700 extent records in it for a file that
size, so it may appear to be fragmented when it really isn't.
Fragmentation is not measured by "having lots of extents in a file".
The extent layout of a file needs to be measured against the pattern
and size of the IOs the application does to that file - the file is
not fragmented if the size and/or packing of extents is optimal for
the access patterns of the application, regardless of the number of
extents in the file...
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:[~2015-10-14 21:35 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-13 21:54 Any way to slow down fragmentation ? Cédric Lemarchand
2015-10-13 22:04 ` Eric Sandeen
2015-10-14 18:29 ` Cédric Lemarchand
2015-10-14 18:36 ` Eric Sandeen
2015-10-14 21:34 ` 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=20151014213453.GP31326@dastard \
--to=david@fromorbit.com \
--cc=cedric.lemarchand@ixblue.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox