linux-api.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: John Garry <john.g.garry@oracle.com>
Cc: brauner@kernel.org, djwong@kernel.org, hch@lst.de,
	viro@zeniv.linux.org.uk, jack@suse.cz, cem@kernel.org,
	linux-fsdevel@vger.kernel.org, dchinner@redhat.com,
	linux-xfs@vger.kernel.org, linux-kernel@vger.kernel.org,
	ojaswin@linux.ibm.com, ritesh.list@gmail.com,
	martin.petersen@oracle.com, linux-ext4@vger.kernel.org,
	linux-block@vger.kernel.org, catherine.hoang@oracle.com,
	linux-api@vger.kernel.org
Subject: Re: [PATCH v8 12/15] xfs: add xfs_file_dio_write_atomic()
Date: Wed, 23 Apr 2025 10:25:25 +0200	[thread overview]
Message-ID: <20250423082525.GB29539@lst.de> (raw)
In-Reply-To: <20250422122739.2230121-13-john.g.garry@oracle.com>

On Tue, Apr 22, 2025 at 12:27:36PM +0000, John Garry wrote:
> Add xfs_file_dio_write_atomic() for dedicated handling of atomic writes.
> 
> The function works based on two operating modes:
> - HW offload, i.e. REQ_ATOMIC-based
> - CoW based with out-of-places write and atomic extent remapping
> 
> The preferred method is HW offload as it will be faster. If HW offload is
> not possible, then we fallback to the CoW-based method.
> 
> HW offload would not be possible for the write length exceeding the HW
> offload limit, the write spanning multiple extents, unaligned disk blocks,
> etc.
> 
> Apart from the write exceeding the HW offload limit, other conditions for
> HW offload can only be detected in the iomap handling for the write. As
> such, we use a fallback method to issue the write if we detect in the
> ->iomap_begin() handler that HW offload is not possible. Special code
> -ENOPROTOOPT is returned from ->iomap_begin() to inform that HW offload
> not possible.

This text could use a little rewrite starting with the fact that the
hardware offload now isn't required to start with and entirely
optional and then flow from the there to state when we can use it
instead of when we can't use it.

Otherwise looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

  reply	other threads:[~2025-04-23  8:25 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-22 12:27 [PATCH v8 00/15] large atomic writes for xfs John Garry
2025-04-22 12:27 ` [PATCH v8 01/15] fs: add atomic write unit max opt to statx John Garry
2025-04-22 12:27 ` [PATCH v8 02/15] xfs: add helpers to compute log item overhead John Garry
2025-04-22 12:27 ` [PATCH v8 03/15] xfs: add helpers to compute transaction reservation for finishing intent items John Garry
2025-04-22 12:27 ` [PATCH v8 04/15] xfs: rename xfs_inode_can_atomicwrite() -> xfs_inode_can_hw_atomicwrite() John Garry
2025-04-22 12:27 ` [PATCH v8 05/15] xfs: ignore HW which cannot atomic write a single block John Garry
2025-04-23  0:38   ` Darrick J. Wong
2025-04-23  7:15     ` John Garry
2025-04-23  8:10       ` Christoph Hellwig
2025-04-23  8:28         ` John Garry
2025-04-23  8:33           ` Christoph Hellwig
2025-04-23 15:12             ` Darrick J. Wong
2025-04-23 15:46               ` Christoph Hellwig
2025-04-22 12:27 ` [PATCH v8 06/15] xfs: allow block allocator to take an alignment hint John Garry
2025-04-22 12:27 ` [PATCH v8 07/15] xfs: refactor xfs_reflink_end_cow_extent() John Garry
2025-04-22 12:27 ` [PATCH v8 08/15] xfs: refine atomic write size check in xfs_file_write_iter() John Garry
2025-04-22 12:27 ` [PATCH v8 09/15] xfs: add xfs_atomic_write_cow_iomap_begin() John Garry
2025-04-23  8:12   ` Christoph Hellwig
2025-04-22 12:27 ` [PATCH v8 10/15] xfs: add large atomic writes checks in xfs_direct_write_iomap_begin() John Garry
2025-04-23  8:16   ` Christoph Hellwig
2025-04-23  8:18     ` John Garry
2025-04-22 12:27 ` [PATCH v8 11/15] xfs: commit CoW-based atomic writes atomically John Garry
2025-04-23  8:23   ` Christoph Hellwig
2025-04-23 14:58     ` Darrick J. Wong
2025-04-23 15:53       ` Christoph Hellwig
2025-04-23 15:58         ` Darrick J. Wong
2025-04-23 16:38           ` John Garry
2025-04-22 12:27 ` [PATCH v8 12/15] xfs: add xfs_file_dio_write_atomic() John Garry
2025-04-23  8:25   ` Christoph Hellwig [this message]
2025-04-23  8:29     ` John Garry
2025-04-22 12:27 ` [PATCH v8 13/15] xfs: add xfs_compute_atomic_write_unit_max() John Garry
2025-04-23  8:26   ` Christoph Hellwig
2025-04-22 12:27 ` [PATCH v8 14/15] xfs: update atomic write limits John Garry
2025-04-23  8:27   ` Christoph Hellwig
2025-04-22 12:27 ` [PATCH v8 15/15] xfs: allow sysadmins to specify a maximum atomic write limit at mount time John Garry
2025-04-23  8:32   ` Christoph Hellwig
2025-04-23 15:01     ` Darrick J. Wong
2025-04-23 15:21       ` Darrick J. Wong

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=20250423082525.GB29539@lst.de \
    --to=hch@lst.de \
    --cc=brauner@kernel.org \
    --cc=catherine.hoang@oracle.com \
    --cc=cem@kernel.org \
    --cc=dchinner@redhat.com \
    --cc=djwong@kernel.org \
    --cc=jack@suse.cz \
    --cc=john.g.garry@oracle.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-block@vger.kernel.org \
    --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=ritesh.list@gmail.com \
    --cc=viro@zeniv.linux.org.uk \
    /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;
as well as URLs for NNTP newsgroup(s).