linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Tso <tytso@mit.edu>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: Andreas Dilger <adilger@clusterfs.com>, linux-ext4@vger.kernel.org
Subject: Re: [RFC][take 4] e2fsprogs: Add ext4migrate
Date: Mon, 7 May 2007 09:20:01 -0400	[thread overview]
Message-ID: <20070507132001.GB17180@thunk.org> (raw)
In-Reply-To: <463E9C53.8000503@linux.vnet.ibm.com>

On Mon, May 07, 2007 at 08:56:11AM +0530, Aneesh Kumar K.V wrote:
> Andreas Dilger wrote:
> >If this code could also (or optionally just) increase the size of inodes
> >it would be very useful.  AFAIK right now it will only change the inodes
> >from block-mapped to extent-mapped?

Actually, changing the inode size is actually going to be more useful
to a larger number of people, since they can use it today to support
in-inode EA's.  In addition, changing the inode size must be done
off-line, whereas it's not so clear that off-line conversion to
extents is the best way to go (more on that below).

One generic concern I have about simply migrating existing files to
use extents is that unless we actually also combine the tool with
defragmentation support, the file ends up being fairly badly
fragmented simply because of the "holes" left in the file from the
indirect blocks.  Therefore the tree ends up being far larger than it
needs to be, and future attempts allocate blocks in that block group
will fill in the holes, further degrading the performance of the
filesystem and whatever file is being written at the time.

The other reason why increasing the inode size would actually be more
valuable is that right now, if we have the disk space, the user can do
on-line migration of a file simply by copying it and then moving it
over the original file --- and if we have delayed allocation support
and sufficient memory, we can avoid the fragmentation problems
currently with the off-line ext4migration approach.

So we may need to think a bit about what's the best way to handle
ext4migrate.  It may be that correct approach is to combine it with a
defragmentation tool, either on-line or off-line.  

> That is correct. My next step is to enhance the tool to support 
> migration to large inodes.

I would actually suggest that the place to add that functionality
would be via "tune2fs -I <inode_size>".  Since mke2fs -I <inode_size>
is used to set the inode size, it makes sense that tune2fs -I would
change the inode size.  Obviously this would have to be done when the
filesystem is not mounted, and tune2fs should abort gracefully if
determines that the filesystem is mounted.

						- Ted

  reply	other threads:[~2007-05-07 13:20 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-04  9:13 [RFC][take 4] e2fsprogs: Add ext4migrate Aneesh Kumar K.V
2007-05-06  5:17 ` Andreas Dilger
2007-05-07  3:26   ` Aneesh Kumar K.V
2007-05-07 13:20     ` Theodore Tso [this message]
2007-05-07 13:46       ` Aneesh Kumar K.V
2007-05-07 15:57         ` Theodore Tso
2007-05-07 21:01         ` Andreas Dilger
2007-05-07 13:59       ` Aneesh Kumar K.V
     [not found] ` <eb16ba5f2c6f399ea747169097434ae84443728f.1178262585.git.aneesh.kumar@linux.vnet.ibm.com>
2007-05-04  9:13   ` [PATCH 1/4] Add unix COW io manager Aneesh Kumar K.V
     [not found]   ` <344eabfd05e36374043e8cd0b4e166a66f88bec6.1178262586.git.aneesh.kumar@linux.vnet.ibm.com>
2007-05-04  9:13     ` [PATCH 2/4] Add extent related functions Aneesh Kumar K.V
     [not found]   ` <1dcc9dea2106570ec314b59bf69e7e3720818a94.1178262586.git.aneesh.kumar@linux.vnet.ibm.com>
2007-05-04  9:13     ` [PATCH 3/4] e2fsprogs: Add ext4migrate Aneesh Kumar K.V
     [not found]   ` <69f2894044fa7c5ad14a59c22e603bc5529dce2a.1178262586.git.aneesh.kumar@linux.vnet.ibm.com>
2007-05-04  9:13     ` [PATCH 4/4] Add ext4replay tool Aneesh Kumar K.V
2007-05-07 13:01   ` [PATCH 1/4] Add unix COW io manager Theodore Tso

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=20070507132001.GB17180@thunk.org \
    --to=tytso@mit.edu \
    --cc=adilger@clusterfs.com \
    --cc=aneesh.kumar@linux.vnet.ibm.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).