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.
Thanks.
[1]: https://lore.kernel.org/lkml/Y%[email protected]/
[2]: https://lore.kernel.org/linux-next/Y%[email protected]/
--
An old man doll... just what I always wanted! - Clara
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...
Honza
--
Jan Kara <[email protected]>
SUSE Labs, CR
Hi all,
On Mon, 6 Mar 2023 13:41:34 +0100 Jan Kara <[email protected]> wrote:
>
> 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...
In that case, it would be nice (for me at least) if the ext4 tree was
now reset to be v6.3-rc1 i.e. get rid of the duplicate commits and the
new stuff that is still being worked on.
--
Cheers,
Stephen Rothwell
On Tue, Mar 07, 2023 at 09:02:03AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> On Mon, 6 Mar 2023 13:41:34 +0100 Jan Kara <[email protected]> wrote:
> >
> > 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...
>
> In that case, it would be nice (for me at least) if the ext4 tree was
> now reset to be v6.3-rc1 i.e. get rid of the duplicate commits and the
> new stuff that is still being worked on.
What duplicate commits? As far as I know there aren't any. My normal
practice is to send a secondary push to fix a few bug fixes targetted
for upcoming release (in this case, 6.3), and then I'll reset to -rc2
or -rc3 for patches that are targetted for the next merge window (in
this case, 6.4).
The data=writeback patches was dropped from dev before the pull
request, and won't show up on dev until they are ready for Linus.
Cheers,
- Ted
Hi Theodore,
On Tue, 7 Mar 2023 11:21:37 -0500 "Theodore Ts'o" <[email protected]> wrote:
>
> What duplicate commits? As far as I know there aren't any. My normal
> practice is to send a secondary push to fix a few bug fixes targetted
> for upcoming release (in this case, 6.3), and then I'll reset to -rc2
> or -rc3 for patches that are targetted for the next merge window (in
> this case, 6.4).
>
> The data=writeback patches was dropped from dev before the pull
> request, and won't show up on dev until they are ready for Linus.
Did you forget to push the dev branch out? The version I have (and still see on git.kernel.org) has commit
2c2dec1e86cc ("ext4: fix incorrect options show of original mount_opt and extend mount_opt2")
at its head, but what you sent to Linus has commit
e3645d72f886 ("ext4: fix incorrect options show of original mount_opt and extend mount_opt2")
at its head.
--
Cheers,
Stephen Rothwell
On Wed, Mar 08, 2023 at 07:45:13AM +1100, Stephen Rothwell wrote:
>
> Did you forget to push the dev branch out? The version I have (and still see on git.kernel.org) has commit
>
> 2c2dec1e86cc ("ext4: fix incorrect options show of original mount_opt and extend mount_opt2")
>
> at its head, but what you sent to Linus has commit
>
> e3645d72f886 ("ext4: fix incorrect options show of original mount_opt and extend mount_opt2")
>
> at its head.
Ah, sorry. I had pushed the tag, but not the branch. My bad. Anyway, fixed.
- Ted