public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
To: John Garry <john.g.garry@oracle.com>,
	brauner@kernel.org, djwong@kernel.org, cem@kernel.org,
	dchinner@redhat.com, hch@lst.de
Cc: linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, ojaswin@linux.ibm.com,
	martin.petersen@oracle.com, tytso@mit.edu,
	linux-ext4@vger.kernel.org, John Garry <john.g.garry@oracle.com>
Subject: Re: [PATCH v6 03/13] iomap: rework IOMAP atomic flags
Date: Mon, 17 Mar 2025 19:14:25 +0530	[thread overview]
Message-ID: <87tt7rsreu.fsf@gmail.com> (raw)
In-Reply-To: <20250313171310.1886394-4-john.g.garry@oracle.com>

John Garry <john.g.garry@oracle.com> writes:

> Flag IOMAP_ATOMIC_SW is not really required. The idea of having this flag
> is that the FS ->iomap_begin callback could check if this flag is set to
> decide whether to do a SW (FS-based) atomic write. But the FS can set
> which ->iomap_begin callback it wants when deciding to do a FS-based
> atomic write.
>
> Furthermore, it was thought that IOMAP_ATOMIC_HW is not a proper name, as
> the block driver can use SW-methods to emulate an atomic write. So change
> back to IOMAP_ATOMIC.
>
> The ->iomap_begin callback needs though to indicate to iomap core that
> REQ_ATOMIC needs to be set, so add IOMAP_F_ATOMIC_BIO for that.
>
> These changes were suggested by Christoph Hellwig and Dave Chinner.
>
> Signed-off-by: John Garry <john.g.garry@oracle.com>
> ---
>  fs/ext4/inode.c       |  5 ++++-
>  fs/iomap/direct-io.c  |  8 +++-----
>  fs/iomap/trace.h      |  2 +-
>  fs/xfs/xfs_iomap.c    |  3 +++
>  include/linux/iomap.h | 12 +++++-------
>  5 files changed, 16 insertions(+), 14 deletions(-)
>
> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index ba2f1e3db7c7..949d74d34926 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -3290,6 +3290,9 @@ static void ext4_set_iomap(struct inode *inode, struct iomap *iomap,
>  	if (map->m_flags & EXT4_MAP_NEW)
>  		iomap->flags |= IOMAP_F_NEW;
>  
> +	if (flags & IOMAP_ATOMIC)
> +		iomap->flags |= IOMAP_F_ATOMIC_BIO;
> +
>  	if (flags & IOMAP_DAX)
>  		iomap->dax_dev = EXT4_SB(inode->i_sb)->s_daxdev;
>  	else
> @@ -3467,7 +3470,7 @@ static inline bool ext4_want_directio_fallback(unsigned flags, ssize_t written)
>  		return false;
>  
>  	/* atomic writes are all-or-nothing */
> -	if (flags & IOMAP_ATOMIC_HW)
> +	if (flags & IOMAP_ATOMIC)
>  		return false;
>  

The changes in ext4 is mostly straight forward. Essentially for
an IOMAP_ATOMIC write requests we are always setting IOMAP_F_ATOMIC_BIO in
the ->iomap_begin() routine. This is done to inform the iomap that this
write request needs to issue an atomic bio, so iomap then goes and sets
REQ_ATOMIC flag in the bio.


>  	/* can only try again if we wrote nothing */
> diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c
> index 9d72b99cb447..c28685fd3362 100644
> --- a/fs/iomap/direct-io.c
> +++ b/fs/iomap/direct-io.c
> @@ -349,7 +349,7 @@ static int iomap_dio_bio_iter(struct iomap_iter *iter, struct iomap_dio *dio)
>  	if (dio->flags & IOMAP_DIO_WRITE) {
>  		bio_opf |= REQ_OP_WRITE;
>  
> -		if (iter->flags & IOMAP_ATOMIC_HW) {
> +		if (iomap->flags & IOMAP_F_ATOMIC_BIO) {
>  			/*
>  			* Ensure that the mapping covers the full write length,
>  			* otherwise we will submit multiple BIOs, which is
> @@ -677,10 +677,8 @@ __iomap_dio_rw(struct kiocb *iocb, struct iov_iter *iter,
>  			iomi.flags |= IOMAP_OVERWRITE_ONLY;
>  		}
>  
> -		if (dio_flags & IOMAP_DIO_ATOMIC_SW)
> -			iomi.flags |= IOMAP_ATOMIC_SW;
> -		else if (iocb->ki_flags & IOCB_ATOMIC)
> -			iomi.flags |= IOMAP_ATOMIC_HW;
> +		if (iocb->ki_flags & IOCB_ATOMIC)
> +			iomi.flags |= IOMAP_ATOMIC;
>  
>  		/* for data sync or sync, we need sync completion processing */
>  		if (iocb_is_dsync(iocb)) {
> diff --git a/fs/iomap/trace.h b/fs/iomap/trace.h
> index 69af89044ebd..9eab2c8ac3c5 100644
> --- a/fs/iomap/trace.h
> +++ b/fs/iomap/trace.h
> @@ -99,7 +99,7 @@ DEFINE_RANGE_EVENT(iomap_dio_rw_queued);
>  	{ IOMAP_FAULT,		"FAULT" }, \
>  	{ IOMAP_DIRECT,		"DIRECT" }, \
>  	{ IOMAP_NOWAIT,		"NOWAIT" }, \
> -	{ IOMAP_ATOMIC_HW,	"ATOMIC_HW" }
> +	{ IOMAP_ATOMIC,		"ATOMIC" }
>  
>  #define IOMAP_F_FLAGS_STRINGS \
>  	{ IOMAP_F_NEW,		"NEW" }, \
> diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
> index 30e257f683bb..9a22ecd794eb 100644
> --- a/fs/xfs/xfs_iomap.c
> +++ b/fs/xfs/xfs_iomap.c
> @@ -831,6 +831,9 @@ xfs_direct_write_iomap_begin(
>  	if (offset + length > i_size_read(inode))
>  		iomap_flags |= IOMAP_F_DIRTY;
>  
> +	if (flags & IOMAP_ATOMIC)
> +		iomap_flags |= IOMAP_F_ATOMIC_BIO;
> +
>  	/*
>  	 * COW writes may allocate delalloc space or convert unwritten COW
>  	 * extents, so we need to make sure to take the lock exclusively here.
> diff --git a/include/linux/iomap.h b/include/linux/iomap.h
> index 9cd93530013c..51f4c13bd17a 100644
> --- a/include/linux/iomap.h
> +++ b/include/linux/iomap.h
> @@ -60,6 +60,9 @@ struct vm_fault;
>   * IOMAP_F_ANON_WRITE indicates that (write) I/O does not have a target block
>   * assigned to it yet and the file system will do that in the bio submission
>   * handler, splitting the I/O as needed.
> + *
> + * IOMAP_F_ATOMIC_BIO indicates that (write) I/O needs to be issued as an
> + * atomic bio, i.e. set REQ_ATOMIC.
>   */


Maybe we can be more explicit here?

IOMAP_F_ATOMIC_BIO flag indicates that write I/O must be issued as an
atomic bio by setting the REQ_ATOMIC flag. Filesystems need to set this
flag to inform iomap that the write I/O operation should be submitted as
an atomic bio.

This definition (or whatever you feel is the better version), should also
go in Documentation/filesystems/iomap/design.rst

>  #define IOMAP_F_NEW		(1U << 0)
>  #define IOMAP_F_DIRTY		(1U << 1)
> @@ -73,6 +76,7 @@ struct vm_fault;
>  #define IOMAP_F_XATTR		(1U << 5)
>  #define IOMAP_F_BOUNDARY	(1U << 6)
>  #define IOMAP_F_ANON_WRITE	(1U << 7)
> +#define IOMAP_F_ATOMIC_BIO	(1U << 8)
>  
>  /*
>   * Flags set by the core iomap code during operations:
> @@ -189,9 +193,8 @@ struct iomap_folio_ops {
>  #else
>  #define IOMAP_DAX		0
>  #endif /* CONFIG_FS_DAX */
> -#define IOMAP_ATOMIC_HW		(1 << 9) /* HW-based torn-write protection */
> +#define IOMAP_ATOMIC		(1 << 9) /* torn-write protection */
>  #define IOMAP_DONTCACHE		(1 << 10)
> -#define IOMAP_ATOMIC_SW		(1 << 11)/* SW-based torn-write protection */

Now that we are killing separate IOMAP_ATOMIC_** names, we may would
like to update the iomap design document as well. Otherwise it will
carry use of IOMAP_ATOMIC_HW & IOMAP_ATOMIC_SW definitions. Instead we
should only keep IOMAP_ATOMIC and update the design info there.

-ritesh

>  
>  struct iomap_ops {
>  	/*
> @@ -503,11 +506,6 @@ struct iomap_dio_ops {
>   */
>  #define IOMAP_DIO_PARTIAL		(1 << 2)
>  
> -/*
> - * Use software-based torn-write protection.
> - */
> -#define IOMAP_DIO_ATOMIC_SW		(1 << 3)
> -
>  ssize_t iomap_dio_rw(struct kiocb *iocb, struct iov_iter *iter,
>  		const struct iomap_ops *ops, const struct iomap_dio_ops *dops,
>  		unsigned int dio_flags, void *private, size_t done_before);
> -- 
> 2.31.1

  parent reply	other threads:[~2025-03-17 14:14 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-13 17:12 [PATCH v6 00/13] large atomic writes for xfs with CoW John Garry
2025-03-13 17:12 ` [PATCH v6 01/13] iomap: inline iomap_dio_bio_opflags() John Garry
2025-03-16 13:40   ` Ritesh Harjani
2025-03-17  6:07   ` Christoph Hellwig
2025-03-13 17:12 ` [PATCH v6 02/13] iomap: comment on atomic write checks in iomap_dio_bio_iter() John Garry
2025-03-17  6:08   ` Christoph Hellwig
2025-03-17  8:22     ` John Garry
2025-03-17 14:16   ` Ritesh Harjani
2025-03-13 17:13 ` [PATCH v6 03/13] iomap: rework IOMAP atomic flags John Garry
2025-03-17  6:11   ` Christoph Hellwig
2025-03-17  9:05     ` John Garry
2025-03-18  5:32       ` Christoph Hellwig
2025-03-18  8:11         ` John Garry
2025-03-17 13:44   ` Ritesh Harjani [this message]
2025-03-17 14:25     ` John Garry
2025-03-13 17:13 ` [PATCH v6 04/13] xfs: pass flags to xfs_reflink_allocate_cow() John Garry
2025-03-17  6:15   ` Christoph Hellwig
2025-03-17  9:17     ` John Garry
2025-03-18  5:33       ` Christoph Hellwig
2025-03-18  8:12         ` John Garry
2025-03-13 17:13 ` [PATCH v6 05/13] xfs: allow block allocator to take an alignment hint John Garry
2025-03-17  6:16   ` Christoph Hellwig
2025-03-13 17:13 ` [PATCH v6 06/13] xfs: switch atomic write size check in xfs_file_write_iter() John Garry
2025-03-17  6:18   ` Christoph Hellwig
2025-03-17  9:17     ` John Garry
2025-03-13 17:13 ` [PATCH v6 07/13] xfs: refactor xfs_reflink_end_cow_extent() John Garry
2025-03-17  6:19   ` Christoph Hellwig
2025-03-13 17:13 ` [PATCH v6 08/13] xfs: reflink CoW-based atomic write support John Garry
2025-03-17  6:20   ` Christoph Hellwig
2025-03-13 17:13 ` [PATCH v6 09/13] xfs: add XFS_REFLINK_ALLOC_EXTSZALIGN John Garry
2025-03-13 18:03   ` Darrick J. Wong
2025-03-17  6:23   ` Christoph Hellwig
2025-03-13 17:13 ` [PATCH v6 10/13] xfs: iomap COW-based atomic write support John Garry
2025-03-16  6:53   ` Ritesh Harjani
2025-03-17  8:54     ` John Garry
2025-03-17 14:20       ` Ritesh Harjani
2025-03-17 14:56         ` John Garry
2025-03-18  5:35           ` Christoph Hellwig
2025-03-17  7:26   ` Christoph Hellwig
2025-03-17 10:18     ` John Garry
2025-03-18  5:39       ` Christoph Hellwig
2025-03-18  8:22         ` John Garry
2025-03-18  8:32           ` Christoph Hellwig
2025-03-18 17:44             ` John Garry
2025-03-19  7:30               ` Christoph Hellwig
2025-03-19 10:24                 ` John Garry
2025-03-20  5:29                   ` Christoph Hellwig
2025-03-20  9:49                     ` John Garry
2025-03-20 14:12                       ` Christoph Hellwig
2025-03-13 17:13 ` [PATCH v6 11/13] xfs: add xfs_file_dio_write_atomic() John Garry
2025-03-17  6:41   ` Christoph Hellwig
2025-03-17  9:36     ` John Garry
2025-03-18  5:43       ` Christoph Hellwig
2025-03-18  8:42         ` John Garry
2025-03-18  8:46           ` Christoph Hellwig
2025-03-18  9:12             ` John Garry
2025-03-13 17:13 ` [PATCH v6 12/13] xfs: commit CoW-based atomic writes atomically John Garry
2025-03-17  6:56   ` Christoph Hellwig
2025-03-17  9:43     ` John Garry
2025-03-13 17:13 ` [PATCH v6 13/13] xfs: update atomic write max size John Garry
2025-03-17  7:25   ` Christoph Hellwig
2025-03-17  9:57     ` John Garry
2025-03-18  5:47       ` Christoph Hellwig
2025-03-18  5:48 ` [PATCH v6 00/13] large atomic writes for xfs with CoW Christoph Hellwig
2025-03-18  8:44   ` John Garry

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=87tt7rsreu.fsf@gmail.com \
    --to=ritesh.list@gmail.com \
    --cc=brauner@kernel.org \
    --cc=cem@kernel.org \
    --cc=dchinner@redhat.com \
    --cc=djwong@kernel.org \
    --cc=hch@lst.de \
    --cc=john.g.garry@oracle.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=ojaswin@linux.ibm.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