All of
 help / color / mirror / Atom feed
From: Jan Kara <>
To: Bagas Sanjaya <>
Cc: Linus Torvalds <>,
	Linux Kernel Mailing List <>,
	Theodore Ts'o <>,
	Andrew Morton <>,
	Matthew Wilcox <>, Jan Kara <>,
	Linux Next Mailing List <>,
	ext4 Development <>
Subject: Re: The state of ext4 tree merging (was Re: Linux 6.3-rc1)
Date: Mon, 6 Mar 2023 13:41:34 +0100	[thread overview]
Message-ID: <20230306124134.hmeuvjhihs4ubpmz@quack3> (raw)
In-Reply-To: <>

On Mon 06-03-23 10:17:56, Bagas Sanjaya wrote:
> On Sun, Mar 05, 2023 at 03:24:41PM -0800, Linus Torvalds wrote:
> > In fact, it was quite nice in a couple of ways: not only didn't I have
> > a hugely compressed merge window where I felt I had to cram as much as
> > possible into the first few days, but the fact that we _have_ had a
> > couple of merge windows where I really asked for people to have
> > everything ready when the merge window opened seems to have set a
> > pattern: the bulk of everything really did come in early.
> > 
> Not so for me watching updates to ext4 merging hell...
> In this merge window, Ted only submitted the first part of ext4 updates
> [1] as noted in the resolution message [2]. The second part didn't make
> through the merge window (PR not sent). As such, the data=writepage
> cleanups have to wait for 6.4 merge window, and it is IMO inconvenient
> for linux-next to contain ext4 tree from next-20230217 for about
> seven weeks, as any enhancements and fixes applied to the tree are
> holding back from testing in linux-next until this hell can be sorted
> out.
> In the long term, I'd like to see a co-maintainer step in to help
> maintaining the tree in case Ted is busy. Of couse I'm not eligible
> for that role (I played as documentation janitor instead), but
> any developer with deep knowledge and experience for the fs and its
> internals should fit the role.

To be fair, the data=journal cleanups got held back only partially due to
the merge issues. Another problem is that they somehow make problems with
filesystem freezing in data=journal mode more frequent and we wanted to
understand (and hopefully fix) that. Of course if Ted could look into this
earlier or I could earlier debug these issues, we could have merged the
cleanups but that's always the case that you have to prioritize and these
cleanups don't have that high priority...

Jan Kara <>

  reply	other threads:[~2023-03-06 12:41 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-05 23:24 Linux 6.3-rc1 Linus Torvalds
2023-03-06  1:41 ` linux-next: stats (Was: Linux 6.3-rc1) Stephen Rothwell
2023-03-06  3:17 ` The state of ext4 tree merging (was " Bagas Sanjaya
2023-03-06 12:41   ` Jan Kara [this message]
2023-03-06 22:02     ` Stephen Rothwell
2023-03-07 16:21       ` Theodore Ts'o
2023-03-07 20:45         ` Stephen Rothwell
2023-03-08  0:45           ` Theodore Ts'o
2023-03-06  8:20 ` Build regressions/improvements in v6.3-rc1 Geert Uytterhoeven
2023-03-06  8:42   ` Geert Uytterhoeven
2023-03-06  8:42     ` Geert Uytterhoeven
2023-03-06  8:42     ` Geert Uytterhoeven
2023-03-06 16:52 ` Linux 6.3-rc1 Guenter Roeck
2023-03-06 18:12   ` Linus Torvalds
2023-03-06 22:02   ` Guenter Roeck
2023-03-08 10:07 ` Luna Jernberg

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230306124134.hmeuvjhihs4ubpmz@quack3 \ \ \ \ \ \ \ \ \ \

* 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.