All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Stan Hoeppner <stan@hardwarefreak.com>, xfs@oss.sgi.com
Subject: Re: XFS defragmentation issue
Date: Sun, 12 Sep 2010 11:01:27 +1000	[thread overview]
Message-ID: <20100912010127.GA411@dastard> (raw)
In-Reply-To: <20100911195702.GB25185@teal.hq.k1024.org>

On Sat, Sep 11, 2010 at 09:57:02PM +0200, Iustin Pop wrote:
> 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 :)

True - I need to look at whether posix_fadvise(POSIX_FADV_DONTNEED)
will clear the bdev pages, and if so that is the easiest solution.
Rewriting xfs_db to use direct IO is a pretty major undertaking...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2010-09-12  1:00 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-10 14:41 XFS defragmentation issue John Lister
2010-09-10 19:00 ` Stan Hoeppner
2010-09-11  6:55 ` John Lister
2010-09-11  8:23   ` Dave Chinner
2010-09-11  8:25     ` John Lister
2010-09-11 19:38     ` Stan Hoeppner
2010-09-11 19:57       ` Iustin Pop
2010-09-12  1:01         ` Dave Chinner [this message]
2010-09-12  8:43       ` Emmanuel Florac
2010-09-12  9:45         ` Stan Hoeppner
2010-09-13  8:05       ` Roel van Meer

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=20100912010127.GA411@dastard \
    --to=david@fromorbit.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.