Message-ID: <20241105154044.GD2578692@frogsfrogsfrogs>
Date: Tue, 5 Nov 2024 07:40:44 -0800
From: "Darrick J. Wong" <djwong@...nel.org>
To: Jens Axboe <axboe@...nel.dk>
Cc: Theodore Ts'o <tytso@....edu>, Carlos Maiolino <cem@...nel.org>,
	"Ritesh Harjani (IBM)" <ritesh.list@...il.com>,
	John Garry <john.g.garry@...cle.com>, brauner@...nel.org,
	Catherine Hoang <catherine.hoang@...cle.com>,
	linux-ext4@...r.kernel.org, Jan Kara <jack@...e.cz>,
	Christoph Hellwig <hch@...radead.org>,
	Ojaswin Mujoo <ojaswin@...ux.ibm.com>, linux-block@...r.kernel.org,
	Dave Chinner <david@...morbit.com>, linux-kernel@...r.kernel.org,
	linux-xfs@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [ANNOUNCE] work tree for untorn filesystem writes

On Tue, Nov 05, 2024 at 08:11:52AM -0700, Jens Axboe wrote:
> On 11/5/24 8:08 AM, Theodore Ts'o wrote:
> > On Tue, Nov 05, 2024 at 05:52:05AM -0700, Jens Axboe wrote:
> >>
> >> Why is this so difficult to grasp? It's a pretty common method for
> >> cross subsystem work - it avoids introducing conflicts when later
> >> work goes into each subsystem, and freedom of either side to send a
> >> PR before the other.
> >>
> >> So please don't start committing the patches again, it'll just cause
> >> duplicate (and empty) commits in Linus's tree.
> > 
> > Jens, what's going on is that in order to test untorn (aka "atomic"
> > although that's a bit of a misnomer) writes, changes are needed in the
> > block, vfs, and ext4 or xfs git trees.  So we are aware that you had
> > taken the block-related patches into the block tree.  What Darrick has
> > done is to apply the the vfs patches on top of the block commits, and
> > then applied the ext4 and xfs patches on top of that.
> 
> And what I'm saying is that is _wrong_. Darrick should be pulling the
> branch that you cut from my email:
> 
> for-6.13/block-atomic
> 
> rather than re-applying patches. At least if the intent is to send that
> branch to Linus. But even if it's just for testing, pretty silly to have
> branches with duplicate commits out there when the originally applied
> patches can just be pulled in.

I *did* start my branch at the end of your block-atomic branch.

Notice how the commits I added yesterday have a parent commitid of
1eadb157947163ca72ba8963b915fdc099ce6cca, which is the head of your
for-6.13/block-atomic branch?

But, it's my fault for not explicitly stating that I did that.  One of
the lessons I apparently keep needing to learn is that senior developers
here don't actually pull and examine the branches I link to in my emails
before hitting Reply All to scold.  You obviously didn't.

Maybe the lesson I really need to learn here is that none of this
constant pointless aggravation in my life is worth it.

--D

> > I'm willing to allow the ext4 patches to flow to Linus's tree without
> > it personally going through the ext4 tree.  If all Maintainers
> > required that patches which touched their trees had to go through
> > their respective trees, it would require multiple (strictly ordered)
> > pull requests during the merge window, or multiple merge windows, to
> 
> That is simply not true. There's ZERO ordering required here. Like I
> also mentioned in my reply, and that you also snipped out, is that no
> ordering is implied here - either tree can send their PR at any time.
> 
> > land these series.  Since you insisted on the block changes had to go
> > through the block tree, we're trying to accomodate you; and also (a)
> > we don't want to have duplicate commits in Linus's tree; and at the
> > same time, (b) but these patches have been waiting to land for almost
> > two years, and we're also trying to make things land a bit more
> > expeditiously.
> 
> Just pull the branch that was created for it... There's zero other
> things in there outside of the 3 commits.
> 
> -- 
> Jens Axboe

Powered by blists - more mailing lists