All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kazuya Mio <k-mio@sx.jp.nec.com>
To: Greg Freemyer <greg.freemyer@gmail.com>
Cc: ext4 <linux-ext4@vger.kernel.org>, Theodore Tso <tytso@mit.edu>,
	linux-fsdevel@vger.kernel.org, ohsm-devel@lists.sourceforge.net,
	dmonakhov@openvz.org
Subject: Re: [RFC][PATCH 0/3] ext4: inode preferred block allocation
Date: Tue, 20 Apr 2010 17:40:41 +0900	[thread overview]
Message-ID: <4BCD6889.2010308@sx.jp.nec.com> (raw)
In-Reply-To: <g2q87f94c371004150922qb636f468t9cf3b6cb8cfd7b03@mail.gmail.com>

2010/04/16 1:22, Greg Freemyer wrote:
> I have a basic understanding how these could be used by e4defrag to
> organize stable data blocks / extents, but is the goal to also allow a
> working set of dynamic files which allocate new data blocks routinely?
> 
> == details / example
> 
> Assume I know that files owned by a specific user (such as the apache
> daemon) need to be collocated to reduce seek times as pages are
> displayed.
> 
> After the fact, I can see the e4defrag moving all files with UID
> apached into a subset of block groups thus increasing locality and
> decreasing seeks.
> 
> But what if those files themselves are dynamically being created /
> extended and thus allocating new data blocks/extents on the fly.   The
> need in that situation would be more along the lines of defining a
> preferred block group range for all files with the same UID.  And all
> of those files would be provided exactly the same block range.

Even if we implement preferred block group range, the problem you said will
occur. Because we don't know how much data will be increased.
If you really want the function, you will be able to materialize your idea by
creating the persistent inode preallocation in struct ext4_sb_info.

I don't have a plan to develop the function of the inode preferred range at
present. This patch has a function enough to realize new feature of e4derag.
Moreover, Andreas said we should not create a second similar mechanism.
http://marc.info/?l=linux-ext4&m=124650093015617&w=4

Best Regards,
Kazuya Mio

      parent reply	other threads:[~2010-04-20  8:40 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-14  8:17 [RFC][PATCH 0/3] ext4: inode preferred block allocation Kazuya Mio
2010-04-15 15:11 ` Andi Kleen
2010-04-16  8:23   ` Kazuya Mio
2010-04-15 16:22 ` Greg Freemyer
2010-04-19 22:39   ` Jan Kara
2010-04-20  8:40   ` Kazuya Mio [this message]

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=4BCD6889.2010308@sx.jp.nec.com \
    --to=k-mio@sx.jp.nec.com \
    --cc=dmonakhov@openvz.org \
    --cc=greg.freemyer@gmail.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=ohsm-devel@lists.sourceforge.net \
    --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.