All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zheng Liu <gnehzuil.liu@gmail.com>
To: Jan Kara <jack@suse.cz>
Cc: linux-ext4@vger.kernel.org, Zheng Liu <wenqing.lz@taobao.com>,
	Theodore Ts'o <tytso@mit.edu>
Subject: Re: [PATCH 7/9 v4] ext4: remove single extent cache
Date: Fri, 1 Feb 2013 11:08:23 +0800	[thread overview]
Message-ID: <20130201030823.GB10176@gmail.com> (raw)
In-Reply-To: <20130131170543.GG4612@quack.suse.cz>

On Thu, Jan 31, 2013 at 06:05:43PM +0100, Jan Kara wrote:
> On Thu 31-01-13 13:17:55, Zheng Liu wrote:
> > From: Zheng Liu <wenqing.lz@taobao.com>
> > 
> > Single extent cache could be removed because we have extent status tree
> > as a extent cache, and it would be better.
>   Just one note: The original extent cache has a capability of containing
> information "there's a hole in range x-y" so we don't have to walk the tree
> again only to find there's nothing for given block. It might be useful to
> put this extent type in extent status tree as well for caching purposes...

Yes, when I removed extent cache, I hesitated whether or not a new status
for a hole is added because that might occupies too much memory.  Let me
consider what happens after adding this status.  If we have a fragmented
file that has 2048 extents, we will cost double spaces to track these
holes in memory when a grep(1) is run.  *But* now I think maybe you are
right because extent status tree has ability to reclaim memory when we
are under a high memory pressure.  Meanwhile tracking all holes for a
file let us avoid to walk the extent tree in disk.

FWIW, I revise the patch (ext4: Remove bogus wait for unwritten extents
in ext4_ind_direct_IO) and I have an idea that let us not flush
unwritten io using extent status tree, and I will try it.

Thanks,
                                                - Zheng

  reply	other threads:[~2013-02-01  2:54 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-31  5:17 [PATCH 0/9 v4] ext4: extent status tree (step2) Zheng Liu
2013-01-31  5:17 ` [PATCH 1/9 v4] ext4: refine extent status tree Zheng Liu
2013-01-31  5:17 ` [PATCH 2/9 v4] ext4: remove EXT4_MAP_FROM_CLUSTER flag Zheng Liu
2013-01-31  5:17 ` [PATCH 3/9 v4] ext4: add physical block and status member into extent status tree Zheng Liu
2013-01-31  5:17 ` [PATCH 4/9 v4] ext4: adjust interfaces of " Zheng Liu
2013-01-31 16:02   ` Jan Kara
2013-02-01  2:51     ` Zheng Liu
2013-01-31  5:17 ` [PATCH 5/9 v4] ext4: track all extent status in " Zheng Liu
2013-01-31 16:50   ` Jan Kara
2013-02-01  5:33     ` Zheng Liu
2013-02-04 11:27       ` Jan Kara
2013-02-05  3:32         ` Zheng Liu
2013-02-05 12:08           ` Jan Kara
2013-02-05 13:24             ` Zheng Liu
2013-02-05 13:27               ` Jan Kara
2013-01-31  5:17 ` [PATCH 6/9 v4] ext4: lookup block mapping " Zheng Liu
2013-01-31  5:17 ` [PATCH 7/9 v4] ext4: remove single extent cache Zheng Liu
2013-01-31 17:05   ` Jan Kara
2013-02-01  3:08     ` Zheng Liu [this message]
2013-01-31  5:17 ` [PATCH 8/9 v4] ext4: adjust some functions for reclaiming extents from extent status tree Zheng Liu
2013-01-31  5:17 ` [PATCH 9/9 v4] ext4: reclaim " Zheng Liu

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=20130201030823.GB10176@gmail.com \
    --to=gnehzuil.liu@gmail.com \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    --cc=wenqing.lz@taobao.com \
    /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.