linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ted Ts'o <tytso@mit.edu>
To: Kazuya Mio <k-mio@sx.jp.nec.com>
Cc: ext4 <linux-ext4@vger.kernel.org>, Andreas Dilger <adilger@dilger.ca>
Subject: Re: [PATCH v3 04/11] e4defrag: Use e2p_get_fragscore() for decision of whether to defrag
Date: Mon, 14 Nov 2011 13:22:17 -0500	[thread overview]
Message-ID: <20111114182217.GH7698@thunk.org> (raw)

On Mon, Nov 14, 2011 at 03:24:31PM +0900, Kazuya Mio wrote:
> This makes e4defrag use e2p_get_fragscore() to calculate fragmentation score.
> If the fragmentation score of the original file is non-zero and
> the fragmentation score of donor file is zero, e4defrag calls
> EXT4_IOC_MOVE_EXT ioctl. Because the fragmentation will get better in this case.
> 
> e4defrag uses 4096 as the threshold of fragmentation because the bigger
> threshold(<4096) has little effect on the performance from the following
> results of my experiment.

One of the things that has long bothered me about the whole
"fragmentation score" concept is that it's not clear to me how well it
works across different sized files.  For your experiment you used a
4GB fragmented file.  But does the threshold change if the file is
substantially smaller?  What if it is substantially larger?

I do like the change to tune2fs that removes printing the
fragmentation score, because I think it's highly misleading what it
means, especially when comparing two file's fragmentation score across
two different files which may be of significantly different size.

Perhaps we would be better off if we just simply called this "number
of discontiguous blocks?" and just left it at that?   Just a thought...

   		 	      	   	   - Ted

             reply	other threads:[~2011-11-14 18:22 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-14 18:22 Ted Ts'o [this message]
2011-11-18  8:40 ` [PATCH v3 04/11] e4defrag: Use e2p_get_fragscore() for decision of whether to defrag Kazuya Mio
  -- strict thread matches above, loose matches on Subject: below --
2011-11-14  6:24 Kazuya Mio

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=20111114182217.GH7698@thunk.org \
    --to=tytso@mit.edu \
    --cc=adilger@dilger.ca \
    --cc=k-mio@sx.jp.nec.com \
    --cc=linux-ext4@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).