Re: [ANNOUNCE] work tree for untorn filesystem writes

["Darrick J. Wong" <djwong@kernel.org>]

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