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 2.6.34.1 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 PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin 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. regards, iustin _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
