All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Monakhov <dmonakhov@openvz.org>
To: Jan Kara <jack@suse.cz>
Cc: ext4 development <linux-ext4@vger.kernel.org>,
	Jan Kara <jack@suse.cz>, Theodore Ts'o <tytso@mit.edu>
Subject: Re: ext4 stable page writes question
Date: Tue, 09 Apr 2013 19:01:32 +0400	[thread overview]
Message-ID: <87r4ijrbn7.fsf@openvz.org> (raw)
In-Reply-To: <20130409142805.GF13672@quack.suse.cz>

On Tue, 9 Apr 2013 16:28:05 +0200, Jan Kara <jack@suse.cz> wrote:
> On Tue 09-04-13 17:38:21, Dmitry Monakhov wrote:
> > According to stable write assumptions (1d1d1a767206fb)
> > grab_cache_page_write_begin() now calls relaxed method wait_for_stable_page()
> > which will wait for writeback to finish only if bdi demand that.
>   Yes.
> 
> > Commit message states that ext4 may not wait
> > But there are a lot of write-paths where we expect that:
> > BUG_ON(!PageLocked(page));
> > BUG_ON(PageWriteback(page));
>   Really? The only places I can find are in writeback path and there we
> have wait_on_page_writeback() (either in write_cache_pages() or in
> ext4_da_writepages()).
> 
> > And the only reason we avoid this bugon is because of commit 47564bfb95b
> > which use following trick to avoid lock inversion over journal_start:
> > page = grab_cache_page_write_begin()
> > unlock_page(page);
> > ext4_journal_start()
> > lock_page(page);
> > wait_on_page_writeback(page); <<<< unconditional wait
>   No, I think this is really independent. ext4 should be fine when write &
> writeback are running in parallel for a page.
> 
> > So as far as I understand this was done just by occasion because
> > ext4_page_mkwrite() use wait_for_stable_page().
> > 
> > So here is my question:  Do we have to wait for page's writeback to
> > finish for all write paths in ext4 code or we may use
> > wait_for_stable_page() and should cleanup all places where 
> > we may trigger BUG_ON(PageWriteback(page));
>   If there's any such place, please tell me how we could trigger it...
move_extent.c:mext_page_mkuptodate() expect that.
IMHO it is reasonable to force behavior here even if we may not do that
on other places because defragmentation code should be 101% reliable
and performance is not important here.
> 
> 								Honza
> -- 
> Jan Kara <jack@suse.cz>
> SUSE Labs, CR

      reply	other threads:[~2013-04-09 15:01 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-09 13:38 ext4 stable page writes question Dmitry Monakhov
2013-04-09 14:28 ` Jan Kara
2013-04-09 15:01   ` Dmitry Monakhov [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=87r4ijrbn7.fsf@openvz.org \
    --to=dmonakhov@openvz.org \
    --cc=jack@suse.cz \
    --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.