All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: tytso@mit.edu
Cc: Dmitry Monakhov <dmonakhov@openvz.org>,
	linux-ext4@vger.kernel.org, jack@suse.cz,
	aneesh.kumar@linux.vnet.ibm.com
Subject: Re: [PATCH] ext4: restart ext4_ext_remove_space() after transaction restart V2
Date: Wed, 26 May 2010 15:46:03 +0200	[thread overview]
Message-ID: <20100526134603.GA3494@quack.suse.cz> (raw)
In-Reply-To: <20100526132352.GA29528@thunk.org>

On Wed 26-05-10 09:23:52, tytso@mit.edu wrote:
> One more thing.  Why do you need EXT4_STATE_EXT_TRUNC?
> 
> The only place which tests it in any kind of real way is
> ext4_ext_truncate_extend_restart(), and it is only called by one
> function, ext4_ext_rm_leaf(), and *it* is only called in one place,
> inside ext4_ext_remove_space(), and *it* surronds the call with
> ext4_set_inode_state(inode, EXT4_STATE_EXT_TRUNC) and
> ext4_clear_inode_state(inode, EXT4_STATE_EXT_TRUNC).
> 
> And while a truncate is happening, no other block allocation can
> happen, so the test in ext4_ext_map_blocks() doesn't seem to do much.
  This is false. As soon as we drop i_data_sem, allocation *can* happen
from writeback path. Because truncate has already invalidated all the pages
past new_size, it must be for some page before new_size but still it could
modify an extent tree node we passed through when looking up our extent...

> (It only clears STATE_EXT_TRUNC if it is set and if the flags
> EXT4_GET_BLOCKS_CREATE is set.  I'm not sure what the point of that
> is, either.)
  I think the idea Dmitry tries to implement is:
When allocation like I describe above happens while we droppped i_data_sem,
restart the whole truncation.

									Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

  reply	other threads:[~2010-05-27 15:53 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-22  4:31 [PATCH] ext4: restart ext4_ext_remove_space() after transaction restart Dmitry Monakhov
2010-04-22  7:33 ` Dmitry Monakhov
2010-04-26 16:09 ` Jan Kara
2010-05-25 13:32 ` tytso
2010-05-25 14:28   ` Dmitry Monakhov
2010-05-25 21:38     ` tytso
2010-05-26  8:53       ` Dmitry Monakhov
2010-05-25 21:44     ` tytso
2010-05-26  9:12       ` Dmitry Monakhov
2010-05-26 11:51         ` [PATCH] ext4: restart ext4_ext_remove_space() after transaction restart V2 Dmitry Monakhov
2010-05-26 13:23           ` tytso
2010-05-26 13:46             ` Jan Kara [this message]
2010-05-26 14:23             ` Dmitry Monakhov
2010-05-26 14:45               ` tytso
2010-05-26 14:47                 ` tytso
2010-05-26 17:22                   ` Dmitry Monakhov
2010-05-25 13:55 ` [PATCH] ext4: restart ext4_ext_remove_space() after transaction restart tytso

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=20100526134603.GA3494@quack.suse.cz \
    --to=jack@suse.cz \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=dmonakhov@openvz.org \
    --cc=linux-ext4@vger.kernel.org \
    --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.