linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Theodore Tso <tytso@mit.edu>
Cc: cmm@us.ibm.com, sandeen@redhat.com, linux-ext4@vger.kernel.org
Subject: Re: [PATCH -v2] ext4: Use inode preallocation with -o noextents
Date: Wed, 4 Jun 2008 09:31:01 +0530	[thread overview]
Message-ID: <20080604040101.GA22348@skywalker> (raw)
In-Reply-To: <20080604022356.GA7094@mit.edu>

On Tue, Jun 03, 2008 at 10:23:56PM -0400, Theodore Tso wrote:
> On Tue, May 20, 2008 at 02:04:22AM +0530, Aneesh Kumar K.V wrote:
> > When mouting ext4 with -o noextents, request for
> > file data blocks from inode prealloc space.
> 
> Aneesh, can you expand on this patch set?  Why is this important?
> What was it doing beforehand?  Is this to replace the use of the block
> reservations code that had been introduced by Mingming in ext3?  Or is
> that a long-term goal?
> 
> Also, it would be nice to add some comments at the beginning of the
> changed functions, explaining what the functions do, what they are
> intended for, what they assumptions they make (i.e., do they assume
> that certain locks are taken), any side effects they make (i.e., this
> function calls get_bh or put_bh to change the refcount on a passed-in
> buffer head).   
> 
> I assume there was a good reason that you renamed the function
> ext4_new_block() to ext4_fsblk_t ext4_new_meta_block(), but why?  Some
> comments would really be useful.
> 
> I asked Mingming what this patch did when I was reviewing it this
> afternoon, since we were both in New Hampshire at the btrfs
> conference.  I couldn't parse the english for the comments, and after
> looking at the patch, it wasn't at all obvious what the patch was
> trying to accomplish.  Even though Mingming had reviewed it maybe two
> weeks ago, she couldn't figure it out completely after looking over
> the patch.  Consider how a someone who isn't intimately familiar with
> the code would be able to figure out either (a) the code, or (b)
> looking over the changeset.  Good code has to be long-term
> maintainable, and some comments would really help in this department.
> 
> Since neither of us couldn't figure it out what the motivation of this
> patch, we've decided to move it to the unstable portion of the patch
> since without some better comments, it's probably not a good idea to
> push it to Linus in this form.
> 
> 						- Ted

When we mount the filesystem with -o noextents currently the block
allocation requests are not using the preallocation feature of mballoc.
mballoc consider the allocation request that doesn't have
ar.flags = EXT4_MB_HINT_DATA set as meta-data allocation and force
them to get the blocks via regular allocator ext4_mb_regular_allocator.
In order to make sure -o noextents (or ext3 format) block allocation
use the preallocation feature we need to set the EXT4_MB_HINT_DATA
while requesting for the blocks. mballoc also needs the
logical block number of the requested block so that it call nicely place
it in the inode prealloc space. This means that we need to differentiate
between data allocation request and meta-data allocation request. The
meta-data allocation is done without setting EXT4_MB_HINT_DATA flag
and they would use the regular allocator where as the data blocks
are requested with EXT4_MB_HINT_DATA set and along with logical block
number so that they can allocate the blocks nicely from the inode prealloc
space. Now with -o noextents we request for blocks via
ext4_alloc_blocks.  Earlier we request for both the data and meta-block
together. Now we can't do that since the data-blocks are allocated based
on the logical block number of the request. So the changes was to split
it such that we first request for meta-data blocks and then request
for data-blocks with the logical block number.


-aneesh

  reply	other threads:[~2008-06-04  4:01 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-19 20:34 [PATCH -v2] ext4: Use inode preallocation with -o noextents Aneesh Kumar K.V
2008-06-04  2:23 ` Theodore Tso
2008-06-04  4:01   ` Aneesh Kumar K.V [this message]
2008-06-05  3:22     ` Theodore Tso
2008-06-05  8:43       ` Aneesh Kumar K.V
2008-06-05 14:55         ` Mingming Cao
2008-06-05 18:24           ` Andreas Dilger
2008-06-05 18:46             ` Aneesh Kumar K.V
2008-06-06 21:33             ` Mingming Cao
2008-06-11  3:26             ` Shen Feng
2008-06-12  9:34               ` Andreas Dilger
2008-06-12 13:41                 ` Eric Sandeen
2008-06-11  3:44           ` Shen Feng
2008-06-16  3:41           ` Shen Feng
2008-06-17  9:42             ` Shen Feng
2008-06-17 10:48               ` Aneesh Kumar K.V
2008-06-18  1:43                 ` Shen Feng
2008-06-05 15:37         ` Theodore Tso
2008-06-05 18:28           ` Andreas Dilger
2008-06-05 19:12             ` Aneesh Kumar K.V
2008-06-05 20:58               ` Andreas Dilger
2008-06-06 16:26           ` Aneesh Kumar K.V

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=20080604040101.GA22348@skywalker \
    --to=aneesh.kumar@linux.vnet.ibm.com \
    --cc=cmm@us.ibm.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 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).