From: Eric Sandeen <sandeen@redhat.com>
To: "Ted Ts'o" <tytso@mit.edu>
Cc: Kazuya Mio <k-mio@sx.jp.nec.com>, ext4 <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH 01/11 RESEND] libe2p: Add new function get_fragment_score()
Date: Fri, 17 Jun 2011 09:20:55 -0500 [thread overview]
Message-ID: <4DFB62C7.5070008@redhat.com> (raw)
In-Reply-To: <20110617031814.GA31884@thunk.org>
On 6/16/11 10:18 PM, Ted Ts'o wrote:
> On Wed, Jun 15, 2011 at 03:33:19PM +0900, Kazuya Mio wrote:
>> This patch adds get_fragment_score() to libe2p. get_fragment_score() returns
>> the fragmentation score. It shows the percentage of extents whose size is
>> smaller than the input argument "threshold".
>
> It perhaps might be useful to also articulate what are the goals of
> this metric. Is just just to decide which files should be
> defragmented, and which should be left alone? Or do you want to be
> able to compare which file is "worse off"?
>
> I can imagine two files that have a score of 100%, but one is much
> worse off than the other. Does that matter? It may or might not,
> depending how you plan to use the fragmentation score, both now and in
> the future. So it might be good to explicitly declare what are the
> goals for this metrics, and its planned use cases.
>
> Regards,
Just as a random datapoint, the xfs_db "frag factor" has been a constant
source of misunderstanding and woe for us. (Granted, it works differently;
it is an fs-wide number representing
((actual - ideal) / actual)
extents in the fs.)
This "% of fragments smaller than threshold" is more easily understandable
and possibly more descriptive, but I think Ted makes good points;
think about how this will be used, and whether the metric is useful.
It's hard to make a single number a) make sense to the user, and b)
be usefully representative of fragmentation "badness" - so I am
feeling very cautious about this idea overall.
To really convey fragmentation "badness" you'd almost want a histogram
of fragment sizes, which is a bit hard to present concisely...
-Eric
> - Ted
next prev parent reply other threads:[~2011-06-17 14:21 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-15 6:33 [PATCH 01/11 RESEND] libe2p: Add new function get_fragment_score() Kazuya Mio
2011-06-16 3:06 ` Andreas Dilger
2011-06-17 3:01 ` Kazuya Mio
2011-06-17 3:18 ` Ted Ts'o
2011-06-17 14:20 ` Eric Sandeen [this message]
2011-06-18 7:19 ` Andreas Dilger
2011-06-18 17:00 ` Greg Freemyer
2011-06-18 17:15 ` Andreas Dilger
2011-06-21 11:28 ` Kazuya Mio
2011-06-23 11:16 ` Greg Freemyer
2011-06-23 11:27 ` Greg Freemyer
2011-06-24 8:28 ` Kazuya Mio
2011-06-26 2:16 ` Greg Freemyer
2011-06-28 10:21 ` Kazuya Mio
2011-06-28 13:53 ` Greg Freemyer
2011-07-01 8:34 ` Kazuya Mio
2011-07-07 10:40 ` Kazuya Mio
2011-06-21 11:26 ` Kazuya Mio
2011-06-21 13:56 ` Ted Ts'o
2011-06-23 8:00 ` Kazuya Mio
2011-06-19 19:55 ` Greg Freemyer
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=4DFB62C7.5070008@redhat.com \
--to=sandeen@redhat.com \
--cc=k-mio@sx.jp.nec.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/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).