On 11/5/24 4:19 AM, Carlos Maiolino wrote: > On Mon, Nov 04, 2024 at 04:43:41PM -0800, Darrick J. Wong wrote: >> Hi everyone, >> >> Nobody else has stepped up to do this, so I've created a work branch for >> the fs side of untorn writes: >> https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=fs-atomic_2024-11-04 >> >> Can you all check this to make sure that I merged it correctly? And >> maybe go test this on your storage hardware? :) >> >> If all goes well then I think the next step is to ask brauner very >> nicely if he'd consider adding this to the vfs trees for 6.13. If not >> then I guess we can submit it ourselves, though we probably ought to ask >> rothwell to add the branch to for-next asap. >> >> PS: We're now past -rc6 so please reply quickly so that this doesn't >> slip yet another cycle. >> >> Catherine: John's on vacation all week, could you please send me the >> latest versions of the xfs_io pwrite-atomic patch and the fstest for it? > > I am kind confused here now. IIRC Jens pulled the first three patches > from John's series into his tree, and John asked me to pull the other > ones. I'm much happier to see a single person pulling the whole series > instead of splitting it into different maintainers though. > > Giving how spread the series is, I'd say going through vfs tree would > be the best place, but I'm not opposed to pull them myself. Guys, not sure why this is so difficult to grasp. I already pulled the initial bits weeks ago, into an immutable branch: https://git.kernel.dk/cgit/linux/log/?h=for-6.13/block-atomic which was subsequently also pulled into for-6.13/block. Whoever wants to stage the xfs bits must simply: 1) Pull the above for-6.13/block-atomic branch 2) Apply XFS bits on top 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 Axboe