All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kazuya Mio <k-mio@sx.jp.nec.com>
To: Andreas Dilger <aedilger@gmail.com>
Cc: Eric Sandeen <sandeen@redhat.com>, "Ted Ts'o" <tytso@mit.edu>,
	ext4 <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH 01/11 RESEND] libe2p: Add new function get_fragment_score()
Date: Tue, 21 Jun 2011 20:28:05 +0900	[thread overview]
Message-ID: <4E008045.1040909@sx.jp.nec.com> (raw)
In-Reply-To: <E94A4A11-B1FB-4D95-87C5-F18190EF333B@gmail.com>

2011/06/18 16:19, Andreas Dilger wrote:
> I was thinking about this, and am wondering if it makes sense to have an absolute score for fragmentation
> instead of a relative one?
>
> By absolute I mean something like fragments per MB or similar. A bad score might be anything>  1. For
> files smaller than 1 MB in size it would scale the ratio to the equivalent if the file was 1MB in size
> (e.g. a 16kB file with 4 fragments would have a score of 256, which is clearly bad).  Large files can
> have a score much less than 1, which is good.

I think fragments per MB is easy to understand. I will fix the library function
to "double e2p_get_fragscore(int fd)". To return fragments per MB, it will
get the number of extents and the total length of extents except the following
special cases:
- The extent whose initialize status is different from the next extent
- There is a hole between the extent and the next extent
- The extent is a tail

The output of filefrag would be as follows:

# filefrag /mnt/mp1/testfile
/mnt/mp1/testfile: 4 extents found, 0.75 fragments/MB

Regards,
Kazuya Mio


  parent reply	other threads:[~2011-06-21 11:29 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
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 [this message]
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=4E008045.1040909@sx.jp.nec.com \
    --to=k-mio@sx.jp.nec.com \
    --cc=aedilger@gmail.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=sandeen@redhat.com \
    --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 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.