From: "Darrick J. Wong" <djwong@kernel.org>
To: Theodore Ts'o <tytso@mit.edu>
Cc: Carlos Maiolino <cem@kernel.org>,
John Garry <john.g.garry@oracle.com>,
"Ritesh Harjani (IBM)" <ritesh.list@gmail.com>,
linux-ext4@vger.kernel.org, Jan Kara <jack@suse.cz>,
Ojaswin Mujoo <ojaswin@linux.ibm.com>,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH v5 7/7] ext4: Add atomic block write documentation
Date: Fri, 16 May 2025 08:10:05 -0700 [thread overview]
Message-ID: <20250516151005.GS25655@frogsfrogsfrogs> (raw)
In-Reply-To: <20250516144817.GB21503@mit.edu>
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.
> 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.
--D
>
> Cheers,
>
> - Ted
>
next prev parent reply other threads:[~2025-05-16 15:10 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-15 19:50 [PATCH v5 0/7] ext4: Add multi-fsblock atomic write support with bigalloc Ritesh Harjani (IBM)
2025-05-15 19:50 ` [PATCH v5 1/7] ext4: Document an edge case for overwrites Ritesh Harjani (IBM)
2025-05-15 19:50 ` [PATCH v5 2/7] ext4: Check if inode uses extents in ext4_inode_can_atomic_write() Ritesh Harjani (IBM)
2025-05-15 19:50 ` [PATCH v5 3/7] ext4: Make ext4_meta_trans_blocks() non-static for later use Ritesh Harjani (IBM)
2025-05-15 19:50 ` [PATCH v5 4/7] ext4: Add support for EXT4_GET_BLOCKS_QUERY_LEAF_BLOCKS Ritesh Harjani (IBM)
2025-05-15 19:50 ` [PATCH v5 5/7] ext4: Add multi-fsblock atomic write support with bigalloc Ritesh Harjani (IBM)
2025-05-15 19:50 ` [PATCH v5 6/7] ext4: Enable support for ext4 multi-fsblock atomic write using bigalloc Ritesh Harjani (IBM)
2025-05-15 19:50 ` [PATCH v5 7/7] ext4: Add atomic block write documentation Ritesh Harjani (IBM)
2025-05-16 8:55 ` John Garry
2025-05-16 12:19 ` Theodore Ts'o
2025-05-16 13:05 ` John Garry
2025-05-16 13:31 ` Carlos Maiolino
2025-05-16 14:48 ` Theodore Ts'o
2025-05-16 15:10 ` Darrick J. Wong [this message]
2025-05-16 18:13 ` Carlos Maiolino
2025-05-16 14:36 ` Ritesh Harjani
2025-05-16 14:15 ` Ritesh Harjani
2025-05-19 10:07 ` [PATCH v5 0/7] ext4: Add multi-fsblock atomic write support with bigalloc Ritesh Harjani
2025-05-19 15:47 ` Theodore Ts'o
2025-05-20 14:40 ` Theodore Ts'o
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250516151005.GS25655@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=cem@kernel.org \
--cc=jack@suse.cz \
--cc=john.g.garry@oracle.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=ojaswin@linux.ibm.com \
--cc=ritesh.list@gmail.com \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.