public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
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
> 

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox