From: Stan Hoeppner <stan@hardwarefreak.com>
To: Kenneth Emerson <kenneth.emerson@gmail.com>
Cc: xfs@oss.sgi.com
Subject: Re: Defragging XFS File Systems
Date: Tue, 07 Jun 2011 07:05:54 -0500 [thread overview]
Message-ID: <4DEE1422.7060902@hardwarefreak.com> (raw)
In-Reply-To: <BANLkTi=40mmE+DCbLcSWBwNQtWpP=N=tXw@mail.gmail.com>
On 6/6/2011 10:52 PM, Kenneth Emerson wrote:
> I hadn't given much thought to fragmentation of my TV recordings volume
> (XFS) until reading through some MythTV-users threads recently that
> mentioned how fragmented an XFS file system could become. After running
> xfs_db, I found out that my fs appeared to be quite bad:
>
> $ sudo xfs_db -c frag -r /dev/mapper/appl_vg-appl_lv
> actual 1138668, ideal 11023, fragmentation factor 99.03%
>
> I then ran xfs_fsr with all defaults (ran for two hours) and then re-ran
>From man xfs_fsr:
It runs for up to two hours after which it records the
filesystem where it left off, so it can start there the next
time. This information is stored in the file
/var/tmp/.fsrlast_xfs. If the information found here is somehow
inconsistent or out of date it is ignored and reorganization
starts at the beginning of the first filesystem found in
/etc/mtab.
If xfs_fsr stopped at 2 hours, multiple additional runs will likely be
required to get good defragmentation.
> xfs_db and got the following results:
>
> $ sudo xfs_db -c frag -r /dev/mapper/appl_vg-appl_lv
The -r above suggests you created a large realtime section for your
MythTV storage. It may be helpful for you to provide xfs_info output
for the heavily fragmented filesystem.
> invalid numrecs (27111) in bmapbtd block
> invalid numrecs (4716) in bmapbtd block
> invalid numrecs (58978) in bmapbtd block
I'll leave these errors for one of the devs to tackle.
> actual 1034793, ideal 11024, fragmentation factor 98.93%
>
> The fragmentation level was reduced,
It was likely reduced much more than this. Dropping caches or
unmounting and remounting the filesystem is often necessary after
running xfs_fsr in order to show the actual fragmentation level. Try:
# echo 3 > /proc/sys/vm/drop_caches
and then run xfs_db again.
> but I was concerned about the error
> messages. Before I go any further, am I corrupting my file system with the
> defragging or are these "invalid numrecs" messages unimportant?
Run 'xfs_check' or 'xfs_repair -n' and post the results.
--
Stan
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2011-06-07 12:05 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 [this message]
[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
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=4DEE1422.7060902@hardwarefreak.com \
--to=stan@hardwarefreak.com \
--cc=kenneth.emerson@gmail.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