public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: "Aneesh Kumar" <aneesh.kumar@gmail.com>
To: Eric <erpo41@gmail.com>
Cc: linux-ext4 <linux-ext4@vger.kernel.org>
Subject: Re: Online defragmentation and ext4migrate
Date: Mon, 21 May 2007 14:03:02 +0530	[thread overview]
Message-ID: <cc723f590705210133w17e84f17t11aae329d1d3062@mail.gmail.com> (raw)
In-Reply-To: <1179519594.6109.40.camel@eric-laptop>

On 5/19/07, Eric <erpo41@gmail.com> wrote:
> On Fri, 2007-05-18 at 18:36 +0530, Aneesh Kumar K.V wrote:
> > The reason why i am asking this is to understand the
> > usefulness of doing a ext4migrate followed by defrag.
> > [...]
> > Also looking at the version 0.4 I see that defrag ioctl only work if we
> > have EXT4_EXTENTS_FL flag set.
>
> ext4migrate is necessary because the current ext4 defrag routines will
> only defragment files stored as extents. AFAIK, converting a file to
> extents does not allow the defrag routine to defragment it "better" than
> an indirect block map inode, but converting any file to extents has
> performance benefits regardless of whether it is later defragmented.
>
> > What are the plans for making defrag work
> > with indirect block map inode ?
>
> I think there is a second set of patches to defragment non-extent
> files.
>

I was looking at this and didn't find the changes needed to defrag the
non extent files.

http://www.mail-archive.com/linux-ext4@vger.kernel.org/msg01522.html



> An even better
> defragmentation routine knows how to balance the time lost to
> defragmentation with the performance gained from a defragmented
> filesystem. IMHO, this requires detailed knowledge of the layout of a
> file's blocks on the disk. Right now, we get this information by looping
> over the FIBMAP ioctl, which I understand can take quite a long time.


With the takashi's code we use ext4_ext_alloc_blocks and see if the
number of extents that we got is less than the number of extents
that we have with the original file that we intent to defrag. I am not sure an
ioctl is involved here.


Well the intent of my mail was to find the advantage of doing an
online migration.
If we are not relocating the blocks corresponding to extent index then doing a
online migration doesn't bring any specific performance bonus.



But yes i agree that there is a performance impact with defrag by
moving the data
blocks closer.

-aneesh

  parent reply	other threads:[~2007-05-21  8:33 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-18 13:06 Online defragmentation and ext4migrate Aneesh Kumar K.V
2007-05-18 20:19 ` Eric
2007-05-18 21:05   ` Andreas Dilger
2007-05-21  8:33   ` Aneesh Kumar [this message]
2007-05-21 10:42     ` Jan Kara
2007-05-21 10:25 ` Takashi Sato
2007-05-21 10:37   ` Aneesh Kumar K.V
2007-05-22  8:35     ` Takashi Sato
2007-05-21 10:38   ` Jan Kara
2007-05-21 13:36     ` Eric
2007-05-22 11:28       ` Jan Kara

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=cc723f590705210133w17e84f17t11aae329d1d3062@mail.gmail.com \
    --to=aneesh.kumar@gmail.com \
    --cc=erpo41@gmail.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