From: Jan Kara <jack@suse.cz>
To: Theodore Ts'o <tytso@mit.edu>
Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH REBASED 0/7] ext4: Cleanup data=journal writeback path
Date: Tue, 28 Feb 2023 14:58:54 +0100 [thread overview]
Message-ID: <20230228135854.ky2zpwal7trz6yg3@quack3> (raw)
In-Reply-To: <20230228051319.4085470-1-tytso@mit.edu>
Hi Ted!
On Tue 28-02-23 00:13:12, Theodore Ts'o wrote:
> This is Jan's data=journal cleanup patch series, previously submitted
> here[1] rebased on top of Linus's patches to address merge conflicts
> with mm-stable, per this discussion[2].
>
> [1] https://lore.kernel.org/r/20230111152736.9608-1-jack@suse.cz
> [2] https://lore.kernel.org/r/Y/k4Jvph15ugcY54@mit.edu
>
> While retesting this patch series, I've noticed a potential regression
> which doesn't trigger before applying the last patch in this series
> (Convert data=journal writeback to use ext4_writepages), but which
> triggers a WARNING in generic/390 about half the time. I've gone back
> and retested, and this was happening before the rebase.
>
> Jan, could you take a look and (1) let me know what you think about my
> patch conflict resolutions and (2) what you think about this warning
> which is occasionally triggered by generic/390? Many thanks!
I went through the patches and they look good to me. I have a side note
that obviously the code isn't quite going to work for folios larger than 1
page but for 1 page folios we should be fine.
Regarding the warning somehow there are dirty pages left after the
procedures freeze_super() goes through to flush all dirty data. That is not
too surprising since in data=journal mode pages get (as a surprise to
freezing code) dirtied when transaction commits. I thought we have this
covered by jbd2_journal_flush() call in ext4_freeze() but maybe there are
some stranded PageDirty bits left? It needs more debugging...
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2023-02-28 13:58 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-28 5:13 [PATCH REBASED 0/7] ext4: Cleanup data=journal writeback path Theodore Ts'o
2023-02-28 5:13 ` [PATCH 1/7] ext4: Update stale comment about write constraints Theodore Ts'o
2023-02-28 5:13 ` [PATCH 2/7] ext4: Use nr_to_write directly in mpage_prepare_extent_to_map() Theodore Ts'o
2023-02-28 5:13 ` [PATCH 3/7] ext4: Mark page for delayed dirtying only if it is pinned Theodore Ts'o
2023-02-28 5:13 ` [PATCH 4/7] ext4: Don't unlock page in ext4_bio_write_page() Theodore Ts'o
2023-02-28 5:13 ` [PATCH 5/7] ext4: Move page unlocking out of mpage_submit_page() Theodore Ts'o
2023-02-28 5:13 ` [PATCH 6/7] ext4: Move mpage_page_done() calls after error handling Theodore Ts'o
2023-02-28 5:13 ` [PATCH 7/7] ext4: Convert data=journal writeback to use ext4_writepages() Theodore Ts'o
2023-02-28 13:58 ` Jan Kara [this message]
2023-03-02 13:37 ` [PATCH REBASED 0/7] ext4: Cleanup data=journal writeback path Theodore Ts'o
2023-03-03 9:29 ` Jan Kara
2023-03-03 10:38 ` Jan Kara
2023-03-08 16:37 ` Jan Kara
2023-03-15 16:16 ` Theodore Ts'o
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=20230228135854.ky2zpwal7trz6yg3@quack3 \
--to=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox