[Top] [All Lists]

Re: XFS defragmentation issue

To: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>
Subject: Re: XFS defragmentation issue
From: Iustin Pop <iusty@xxxxxxxxx>
Date: Sat, 11 Sep 2010 21:57:02 +0200
Cc: xfs@xxxxxxxxxxx
In-reply-to: <4C8BDAC8.8010203@xxxxxxxxxxxxxxxxx>
Mail-followup-to: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>, xfs@xxxxxxxxxxx
References: <4C8A4395.5070702@xxxxxxxxxxxxx> <4C8B27E4.2050102@xxxxxxxxxxxxx> <20100911082330.GG705@dastard> <4C8BDAC8.8010203@xxxxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.20 (2009-06-14)
On Sat, Sep 11, 2010 at 02:38:48PM -0500, Stan Hoeppner wrote:
> Dave Chinner put forth on 9/11/2010 3:23 AM:
> > On Sat, Sep 11, 2010 at 07:55:32AM +0100, John Lister wrote:
> >>  Stan Hoeppner wrote on 9/10/2010 14:00
> >>>> On 10/09/2010 15:41, John Lister wrote:
> >>> Try unmounting and remounting the filesystem, and see if the various
> >>> tools all report the same thing afterwards. This solved the exact same
> >>> problem for me very recently, though I'm on kernel and xfsprogs
> >>> 2.9.8.
> >>
> >> Cheers, that got rid of most of it, there is still a slight
> >> discrepency  (50 extra fragments) which I can live with.
> > 
> > xfs_db used buffered IO on the block device, which is not coherent
> > with the filesystem. If you are using it on an active filesystem,
> > then running "echo 1 > /proc/sys/vm/drop_caches" before you run
> > xfs_db should make it read from disk at least once....

I wonder if xfs_db shouldn't use by default direct I/O, or at least take
a flag to allow it to do direct I/O only against the blocks it needs.
Dropping the entire caches on a big box is not nice :)

> That's good to know Dave.  Thanks.  I created a short-name script a
> while back with "echo 3 > /proc/sys/vm/drop_caches" merely so I could
> "clear the baffles" now and then.  Looks like it now has multiple uses
> (if I can just remember to use it in this context).
> Out of curiosity, who here schedules automatic xfs_fsr runs, and with
> what frequency?  Currently I just run it manually now and then when
> performance starts to seem sluggish.

This is my setup, on a machine with multiple XFS filesystems:

$ cat /etc/cron.d/xfsfsr 

0   01  *   *   7   root    xfs_fsr -v

I've set it up a few years back and, except for a few rare bugs in 2.6.x
which are then fixed in 2.6.x.y, I've had no issues.


<Prev in Thread] Current Thread [Next in Thread>