linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tomasz Chmielewski <mangoo@wpkg.org>
To: Kazuya Mio <k-mio@sx.jp.nec.com>
Cc: linux-ext4@vger.kernel.org
Subject: Re: [PATCH 00/11 RESEND] e4defrag: fragmentation score rework and cleanups
Date: Thu, 16 Jun 2011 10:18:26 +0200	[thread overview]
Message-ID: <4DF9BC52.40203@wpkg.org> (raw)
In-Reply-To: <4DF99052.8020201@sx.jp.nec.com>

On 16.06.2011 07:10, Kazuya Mio wrote:
> 2011/06/16 5:31, Tomasz Chmielewski wrote:
>> Out of curiosity: is there a minimal kernel version requirement (one
>> which can be safely used with e4defrag)?
>
> EXT4_IOC_MOVE_EXT ioctl was merged 2.6.31. And then some bugfix were merged
> before 2.6.35. I suggest you to build 2.6.35 or later if you try to do
> e4defrag.
>
> e4defrag also merged some bugfix like this patch, so you should use
> the latest e4defrag.

Thanks for clarification.


> If you find out something about online defrag, please post a comment.

My main usage for e4defrag would be defragmenting virtual guest (like 
KVM) file-based images.

These images are typically quite small when created (i.e. qcow2, or a 
"raw", sparse file), but grow in time, which leads to serious fragmentation.

I noticed that when using e4defrag on such a file-based image, while the 
guest is running (i.e. the file is in use), all IO from that guest to 
the disk (disk is this file) is "frozen".

In other words, as soon as we run e4defrag, any guest writes to that 
file will only complete if e4defrag finishes. As the images can be quite 
big, it can mean guest IO can be frozen even for hours.


Is it a known/intended limitation (at least, it behaved like this when I 
tried e4defrag a few months ago)?

In some cases, it can be a serious drawback, potentially leading to 
filesystem corruption in the guest - if guest block layer is SCSI, with 
default settings (at least in Linux) it may detect that no IO happened 
for some time, and just "offline" the disk.


-- 
Tomasz Chmielewski
http://wpkg.org

  reply	other threads:[~2011-06-16  8:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-15 20:31 [PATCH 00/11 RESEND] e4defrag: fragmentation score rework and cleanups Tomasz Chmielewski
2011-06-16  5:10 ` Kazuya Mio
2011-06-16  8:18   ` Tomasz Chmielewski [this message]
2011-06-17  5:13     ` Kazuya Mio
2011-06-17 13:08       ` Greg Freemyer
  -- strict thread matches above, loose matches on Subject: below --
2011-06-15  6:33 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=4DF9BC52.40203@wpkg.org \
    --to=mangoo@wpkg.org \
    --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).