From: "Darrick J. Wong" <djwong@kernel.org>
To: John Garry <john.g.garry@oracle.com>
Cc: brauner@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 v7 13/14] xfs: update atomic write limits
Date: Tue, 15 Apr 2025 09:26:00 -0700 [thread overview]
Message-ID: <20250415162600.GQ25675@frogsfrogsfrogs> (raw)
In-Reply-To: <20250415121425.4146847-14-john.g.garry@oracle.com>
On Tue, Apr 15, 2025 at 12:14:24PM +0000, John Garry wrote:
> Update the limits returned from xfs_get_atomic_write_{min, max, max_opt)().
>
> No reflink support always means no CoW-based atomic writes.
>
> For updating xfs_get_atomic_write_min(), we support blocksize only and that
> depends on HW or reflink support.
>
> For updating xfs_get_atomic_write_max(), for no reflink, we are limited to
> blocksize but only if HW support. Otherwise we are limited to combined
> limit in mp->m_atomic_write_unit_max.
>
> For updating xfs_get_atomic_write_max_opt(), ultimately we are limited by
> the bdev atomic write limit. If xfs_get_atomic_write_max() does not report
> > 1x blocksize, then just continue to report 0 as before.
>
> Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
> [djwong: update comments in the helper functions]
Same here, there should be a
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
after this comment.
--D
> Signed-off-by: John Garry <john.g.garry@oracle.com>
> ---
> fs/xfs/xfs_file.c | 2 +-
> fs/xfs/xfs_iops.c | 53 +++++++++++++++++++++++++++++++++++++++++------
> 2 files changed, 48 insertions(+), 7 deletions(-)
>
> diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c
> index 81a377f65aa3..d1ddbc4a98c3 100644
> --- a/fs/xfs/xfs_file.c
> +++ b/fs/xfs/xfs_file.c
> @@ -1557,7 +1557,7 @@ xfs_file_open(
> if (xfs_is_shutdown(XFS_M(inode->i_sb)))
> return -EIO;
> file->f_mode |= FMODE_NOWAIT | FMODE_CAN_ODIRECT;
> - if (xfs_inode_can_hw_atomicwrite(XFS_I(inode)))
> + if (xfs_get_atomic_write_min(XFS_I(inode)))
> file->f_mode |= FMODE_CAN_ATOMIC_WRITE;
> return generic_file_open(inode, file);
> }
> diff --git a/fs/xfs/xfs_iops.c b/fs/xfs/xfs_iops.c
> index 3b5aa39dbfe9..183524d06bc3 100644
> --- a/fs/xfs/xfs_iops.c
> +++ b/fs/xfs/xfs_iops.c
> @@ -605,27 +605,68 @@ unsigned int
> xfs_get_atomic_write_min(
> struct xfs_inode *ip)
> {
> - if (!xfs_inode_can_hw_atomicwrite(ip))
> - return 0;
> + struct xfs_mount *mp = ip->i_mount;
> +
> + /*
> + * If we can complete an atomic write via atomic out of place writes,
> + * then advertise a minimum size of one fsblock. Without this
> + * mechanism, we can only guarantee atomic writes up to a single LBA.
> + *
> + * If out of place writes are not available, we can guarantee an atomic
> + * write of exactly one single fsblock if the bdev will make that
> + * guarantee for us.
> + */
> + if (xfs_inode_can_hw_atomicwrite(ip) || xfs_has_reflink(mp))
> + return mp->m_sb.sb_blocksize;
>
> - return ip->i_mount->m_sb.sb_blocksize;
> + return 0;
> }
>
> unsigned int
> xfs_get_atomic_write_max(
> struct xfs_inode *ip)
> {
> - if (!xfs_inode_can_hw_atomicwrite(ip))
> + struct xfs_mount *mp = ip->i_mount;
> +
> + /*
> + * If out of place writes are not available, we can guarantee an atomic
> + * write of exactly one single fsblock if the bdev will make that
> + * guarantee for us.
> + */
> + if (!xfs_has_reflink(mp)) {
> + if (xfs_inode_can_hw_atomicwrite(ip))
> + return mp->m_sb.sb_blocksize;
> return 0;
> + }
>
> - return ip->i_mount->m_sb.sb_blocksize;
> + /*
> + * If we can complete an atomic write via atomic out of place writes,
> + * then advertise a maximum size of whatever we can complete through
> + * that means. Hardware support is reported via max_opt, not here.
> + */
> + if (XFS_IS_REALTIME_INODE(ip))
> + return XFS_FSB_TO_B(mp, mp->m_groups[XG_TYPE_RTG].awu_max);
> + return XFS_FSB_TO_B(mp, mp->m_groups[XG_TYPE_AG].awu_max);
> }
>
> unsigned int
> xfs_get_atomic_write_max_opt(
> struct xfs_inode *ip)
> {
> - return 0;
> + struct xfs_buftarg *target = xfs_inode_buftarg(ip);
> + unsigned int awu_max = xfs_get_atomic_write_max(ip);
> +
> + /* if the max is 1x block, then just keep behaviour that opt is 0 */
> + if (awu_max <= ip->i_mount->m_sb.sb_blocksize)
> + return 0;
> +
> + /*
> + * Advertise the maximum size of an atomic write that we can tell the
> + * block device to perform for us. In general the bdev limit will be
> + * less than our out of place write limit, but we don't want to exceed
> + * the awu_max.
> + */
> + return min(awu_max, target->bt_bdev_awu_max);
> }
>
> static void
> --
> 2.31.1
>
>
next prev parent reply other threads:[~2025-04-15 16:26 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-15 12:14 [PATCH v7 00/14] large atomic writes for xfs John Garry
2025-04-15 12:14 ` [PATCH v7 01/14] fs: add atomic write unit max opt to statx John Garry
2025-04-15 12:14 ` [PATCH v7 02/14] xfs: add helpers to compute log item overhead John Garry
2025-04-15 12:14 ` [PATCH v7 03/14] xfs: add helpers to compute transaction reservation for finishing intent items John Garry
2025-04-15 12:14 ` [PATCH v7 04/14] xfs: rename xfs_inode_can_atomicwrite() -> xfs_inode_can_hw_atomicwrite() John Garry
2025-04-15 12:14 ` [PATCH v7 05/14] xfs: allow block allocator to take an alignment hint John Garry
2025-04-15 12:14 ` [PATCH v7 06/14] xfs: refactor xfs_reflink_end_cow_extent() John Garry
2025-04-15 12:14 ` [PATCH v7 07/14] xfs: refine atomic write size check in xfs_file_write_iter() John Garry
2025-04-15 12:14 ` [PATCH v7 08/14] xfs: add xfs_atomic_write_cow_iomap_begin() John Garry
2025-04-15 12:14 ` [PATCH v7 09/14] xfs: add large atomic writes checks in xfs_direct_write_iomap_begin() John Garry
2025-04-15 17:34 ` Darrick J. Wong
2025-04-15 17:46 ` John Garry
2025-04-15 12:14 ` [PATCH v7 10/14] xfs: commit CoW-based atomic writes atomically John Garry
2025-04-15 12:14 ` [PATCH v7 11/14] xfs: add xfs_file_dio_write_atomic() John Garry
2025-04-21 4:00 ` Darrick J. Wong
2025-04-21 5:47 ` John Garry
2025-04-21 16:42 ` Darrick J. Wong
2025-04-23 5:42 ` Christoph Hellwig
2025-04-23 8:19 ` Christoph Hellwig
2025-04-23 14:51 ` Darrick J. Wong
2025-04-23 14:53 ` Darrick J. Wong
2025-04-21 21:18 ` Luis Chamberlain
2025-04-22 6:08 ` John Garry
2025-04-23 5:18 ` Luis Chamberlain
2025-04-23 7:08 ` John Garry
2025-04-23 7:36 ` Luis Chamberlain
2025-04-23 5:44 ` Christoph Hellwig
2025-04-23 7:02 ` John Garry
2025-04-15 12:14 ` [PATCH v7 12/14] xfs: add xfs_compute_atomic_write_unit_max() John Garry
2025-04-15 16:25 ` Darrick J. Wong
2025-04-15 16:35 ` John Garry
2025-04-15 16:39 ` Darrick J. Wong
2025-04-15 12:14 ` [PATCH v7 13/14] xfs: update atomic write limits John Garry
2025-04-15 16:26 ` Darrick J. Wong [this message]
2025-04-15 12:14 ` [PATCH v7 14/14] xfs: allow sysadmins to specify a maximum atomic write limit at mount time John Garry
2025-04-15 15:35 ` Randy Dunlap
2025-04-15 16:55 ` Darrick J. Wong
2025-04-15 22:36 ` [PATCH v7.1 " Darrick J. Wong
2025-04-16 10:08 ` John Garry
2025-04-16 16:26 ` 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=20250415162600.GQ25675@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=brauner@kernel.org \
--cc=catherine.hoang@oracle.com \
--cc=cem@kernel.org \
--cc=dchinner@redhat.com \
--cc=hch@lst.de \
--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 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.