public inbox for linux-xfs@vger.kernel.org
 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, cem@kernel.org,
	dchinner@redhat.com, hch@lst.de, linux-xfs@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	ojaswin@linux.ibm.com, ritesh.list@gmail.com,
	martin.petersen@oracle.com, tytso@mit.edu,
	linux-ext4@vger.kernel.org
Subject: Re: [PATCH v6 11/13] xfs: add xfs_file_dio_write_atomic()
Date: Mon, 17 Mar 2025 07:41:09 +0100	[thread overview]
Message-ID: <20250317064109.GA27621@lst.de> (raw)
In-Reply-To: <20250313171310.1886394-12-john.g.garry@oracle.com>

On Thu, Mar 13, 2025 at 05:13:08PM +0000, John Garry wrote:
> + * REQ_ATOMIC-based is the preferred method, and is attempted first. If this
> + * method fails due to REQ_ATOMIC-related constraints, then we retry with the
> + * COW-based method. The REQ_ATOMIC-based method typically will fail if the
> + * write spans multiple extents or the disk blocks are misaligned.

It is only preferred if actually supported by the underlying hardware.
If it isn't it really shouldn't even be tried, as that is just a waste
of cycles.

Also a lot of comment should probably be near the code not on top
of the function as that's where people would look for them.

> +static noinline ssize_t
> +xfs_file_dio_write_atomic(
> +	struct xfs_inode	*ip,
> +	struct kiocb		*iocb,
> +	struct iov_iter		*from)
> +{
> +	unsigned int		iolock = XFS_IOLOCK_SHARED;
> +	unsigned int		dio_flags = 0;
> +	const struct iomap_ops	*dops = &xfs_direct_write_iomap_ops;
> +	ssize_t			ret;
> +
> +retry:
> +	ret = xfs_ilock_iocb_for_write(iocb, &iolock);
> +	if (ret)
> +		return ret;
> +
> +	ret = xfs_file_write_checks(iocb, from, &iolock, NULL);
> +	if (ret)
> +		goto out_unlock;
> +
> +	if (dio_flags & IOMAP_DIO_FORCE_WAIT)
> +		inode_dio_wait(VFS_I(ip));
> +
> +	trace_xfs_file_direct_write(iocb, from);
> +	ret = iomap_dio_rw(iocb, from, dops, &xfs_dio_write_ops,
> +			dio_flags, NULL, 0);

The normal direct I/O path downgrades the iolock to shared before
doing the I/O here.  Why isn't that done here?

> +	if (ret == -EAGAIN && !(iocb->ki_flags & IOCB_NOWAIT) &&
> +	    dops == &xfs_direct_write_iomap_ops) {

This should probably explain the unusual use of EGAIN.  Although I
still feel that picking a different error code for the fallback would
be much more maintainable.

> +		xfs_iunlock(ip, iolock);
> +		dio_flags = IOMAP_DIO_FORCE_WAIT;

I notice the top of function comment mentions the IOMAP_DIO_FORCE_WAIT
flag.  Maybe use the chance to write a full sentence here or where
it is checked to explain the logic a bit better?

>   * Handle block unaligned direct I/O writes
>   *
> @@ -840,6 +909,10 @@ xfs_file_dio_write(
>  		return xfs_file_dio_write_unaligned(ip, iocb, from);
>  	if (xfs_is_zoned_inode(ip))
>  		return xfs_file_dio_write_zoned(ip, iocb, from);
> +
> +	if (iocb->ki_flags & IOCB_ATOMIC)
> +		return xfs_file_dio_write_atomic(ip, iocb, from);
> +

Either keep space between all the conditional calls or none.  I doubt
just stick to the existing style.


  reply	other threads:[~2025-03-17  6:41 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
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 [this message]
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=20250317064109.GA27621@lst.de \
    --to=hch@lst.de \
    --cc=brauner@kernel.org \
    --cc=cem@kernel.org \
    --cc=dchinner@redhat.com \
    --cc=djwong@kernel.org \
    --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=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