On Fri, May 16, 2025 at 08:10:05AM -0700, Darrick J. Wong wrote: > On Fri, May 16, 2025 at 10:48:17AM -0400, Theodore Ts'o wrote: > > On Fri, May 16, 2025 at 03:31:17PM +0200, Carlos Maiolino wrote: > > > > > > This is likely the final state for XFS merge-window and I hope to > > > send it to Linus as soon as the merge window opens. > > > > Very cool! > > > > I've taken a quick peek, and it looks like the only XFS-specific > > atomic writes is an XFS mount option. Am I missing anything? > > > > I want to keep merging the ext4 and xfs atomic write patchsets simple, > > so I'd prefer not to have any git-level dependencies on the branches. > > If we're confident that the xfs changes are going to land at the next > > merge window, > > /I/ for one hope that the xfs changes land this time around. Yes, so far everything looks good, and we've atomic writes on for-next for a while as I mentioned too (although a rebase yesterday required to have those patches re-introduced with different hashes, the content is still the same). Ted, I'm not exactly sure what kind of git-level dependency you have in mind, but just to play safe here, bear in mind the atomic writes in merged on top of Axboe's block-6.15. > > > given that the ext4 patch set is pretty much ready to > > land in the ext4 tree, how about updating the documentation in a > > follow-up patch. > > > > I can either append the commit which generalizes the documentation to > > the ext4 tree, or if it turns out that there is a v6 needed of the > > ext4 atomic write patchset, we can fold the documentation update into > > the "ext4: add atomic block write documentation" commit and rename it > > to "Documentation: add atomic write block documentation." > > > > Does that seem reasonable? > > I think it's ok to combine them after the merge. It would be useful to > have a single programmer's guide that takes a person through the whole > process of determining the block device's atomic write capabilities, > formatting either an XFS or ext4 filesystem appropriately, and then > presents a toy program to discover the atomic write limits on an open > file and uses that to queue a single IO. This sounds indeed good to me too. Have a nice weekend all. Carlos > > --D > > > > > Cheers, > > > > - Ted > > >
