From: Dave Chinner <david@fromorbit.com>
To: Stan Hoeppner <stan@hardwarefreak.com>
Cc: Michael Monnerie <michael.monnerie@is.it-management.at>,
Kenneth Emerson <kenneth.emerson@gmail.com>,
xfs@oss.sgi.com
Subject: Re: Defragging XFS File Systems
Date: Sat, 11 Jun 2011 03:56:56 +1000 [thread overview]
Message-ID: <20110610175656.GW32466@dastard> (raw)
In-Reply-To: <4DF10FDF.1090508@hardwarefreak.com>
On Thu, Jun 09, 2011 at 01:24:31PM -0500, Stan Hoeppner wrote:
> On 6/9/2011 5:12 AM, Michael Monnerie wrote:
> > On Donnerstag, 9. Juni 2011 Stan Hoeppner wrote:
> >> When is running xfs_fsr recommended?
> >
> > Good question. One case that comes to my mind is a filesystem that was
> > used a long time when filled >85%, which has now either been expanded or
> > files removed so you have a lot of space again, and you want to defrag
> > all those files that have been badly fragmented.
> >
> >> I scheduled it twice a week some time ago due to a filesystem
> >> containing active mbox files. I did so because they became so
> >> heavily fragmented in short order, especially those swallowing
> >> copious amounts of list mail. Before cron'ing xfs_fsr I was seeing
> >> mbox files with over 1000 fragmented extents, and increasing MUA
> >> latency as the files became more fragmented. The filesystem is
> >> currently 90% free.
> >
> > This is also an example where defrag may help. You have 10% usage, so
> > there's enough space. Maybe your usage fits the mount option
> > "allocsize",
>
> I tried allocsize=1m but it didn't seem to help already existing files.
> I simply don't think there's much that can be done in filesystem logic
> to keep long lived constantly appended files from fragmenting, short of
YOu can stop XFS from truncating speculative preallocation beyond
EOF by either telling the inode it has preallocated space or
or turning it into a an append-only file. e.g.
$ xfs_io -f -c "resvsp 0 4k" <file>
or
$ sudo chattr +a <file>
Either way, XFS won't truncate extents beyond EOF on file close for
such a file and that should prevent most future fragmentation of the
file.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2011-06-10 17:57 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-07 3:52 Defragging XFS File Systems Kenneth Emerson
2011-06-07 5:48 ` Stewart Smith
2011-06-07 12:05 ` Stan Hoeppner
[not found] ` <BANLkTikBSL8-eTAbF7a94ckLuZNyWCM=Eg@mail.gmail.com>
2011-06-08 21:00 ` Stan Hoeppner
2011-06-09 5:49 ` Michael Monnerie
2011-06-09 8:13 ` Stan Hoeppner
2011-06-09 10:12 ` Michael Monnerie
2011-06-09 18:24 ` Stan Hoeppner
2011-06-10 17:56 ` Dave Chinner [this message]
2011-06-11 1:12 ` Stan Hoeppner
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=20110610175656.GW32466@dastard \
--to=david@fromorbit.com \
--cc=kenneth.emerson@gmail.com \
--cc=michael.monnerie@is.it-management.at \
--cc=stan@hardwarefreak.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