From: Dave Chinner <david@fromorbit.com>
To: John Garry <john.g.garry@oracle.com>
Cc: brauner@kernel.org, djwong@kernel.org, cem@kernel.org,
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 v4 05/12] iomap: Support SW-based atomic writes
Date: Mon, 10 Mar 2025 08:51:08 +1100 [thread overview]
Message-ID: <Z84NTP5tyHEVLNbA@dread.disaster.area> (raw)
In-Reply-To: <20250303171120.2837067-6-john.g.garry@oracle.com>
On Mon, Mar 03, 2025 at 05:11:13PM +0000, John Garry wrote:
> Currently atomic write support requires dedicated HW support. This imposes
> a restriction on the filesystem that disk blocks need to be aligned and
> contiguously mapped to FS blocks to issue atomic writes.
>
> XFS has no method to guarantee FS block alignment for regular,
> non-RT files. As such, atomic writes are currently limited to 1x FS block
> there.
>
> To deal with the scenario that we are issuing an atomic write over
> misaligned or discontiguous data blocks - and raise the atomic write size
> limit - support a SW-based software emulated atomic write mode. For XFS,
> this SW-based atomic writes would use CoW support to issue emulated untorn
> writes.
>
> It is the responsibility of the FS to detect discontiguous atomic writes
> and switch to IOMAP_DIO_ATOMIC_SW mode and retry the write. Indeed,
> SW-based atomic writes could be used always when the mounted bdev does
> not support HW offload, but this strategy is not initially expected to be
> used.
So now seeing how these are are to be used, these aren't "hardware"
and "software" atomic IOs. They are block layer vs filesystem atomic
IOs.
We can do atomic IOs in software in the block layer drivers (think
loop or dm-thinp) rather than off-loading to storage hardware.
Hence I think these really need to be named after the layer that
will provide the atomic IO guarantees, because "hw" and "sw" as they
are currently used are not correct. e.g something like
IOMAP_FS_ATOMIC and IOMAP_BDEV_ATOMIC which indicates which layer
should be providing the atomic IO constraints and guarantees.
-Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2025-03-09 21:51 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-03 17:11 [PATCH v4 00/12] large atomic writes for xfs with CoW John Garry
2025-03-03 17:11 ` [PATCH v4 01/12] xfs: Pass flags to xfs_reflink_allocate_cow() John Garry
2025-03-03 17:11 ` [PATCH v4 02/12] iomap: Rename IOMAP_ATOMIC -> IOMAP_ATOMIC_HW John Garry
2025-03-05 12:57 ` Carlos Maiolino
2025-03-06 8:50 ` Christian Brauner
2025-03-03 17:11 ` [PATCH v4 03/12] xfs: Switch atomic write size check in xfs_file_write_iter() John Garry
2025-03-03 17:11 ` [PATCH v4 04/12] xfs: Refactor xfs_reflink_end_cow_extent() John Garry
2025-03-03 17:11 ` [PATCH v4 05/12] iomap: Support SW-based atomic writes John Garry
2025-03-09 21:51 ` Dave Chinner [this message]
2025-03-10 10:44 ` John Garry
2025-03-10 17:21 ` Darrick J. Wong
2025-03-03 17:11 ` [PATCH v4 06/12] iomap: Lift blocksize restriction on " John Garry
2025-03-03 17:11 ` [PATCH v4 07/12] xfs: Reflink CoW-based atomic write support John Garry
2025-03-03 17:11 ` [PATCH v4 08/12] xfs: Iomap SW-based " John Garry
2025-03-03 17:11 ` [PATCH v4 09/12] xfs: Add xfs_file_dio_write_atomic() John Garry
2025-03-10 13:39 ` Ritesh Harjani
2025-03-10 15:24 ` John Garry
2025-03-10 17:25 ` Darrick J. Wong
2025-03-03 17:11 ` [PATCH v4 10/12] xfs: Commit CoW-based atomic writes atomically John Garry
2025-03-03 17:11 ` [PATCH v4 11/12] xfs: Update atomic write max size John Garry
2025-03-10 10:06 ` Carlos Maiolino
2025-03-10 10:54 ` John Garry
2025-03-10 11:11 ` Carlos Maiolino
2025-03-10 11:20 ` John Garry
2025-03-10 12:38 ` Carlos Maiolino
2025-03-10 12:59 ` John Garry
2025-03-03 17:11 ` [PATCH v4 12/12] xfs: Allow block allocator to take an alignment hint John Garry
2025-03-09 22:03 ` Dave Chinner
2025-03-10 12:10 ` John Garry
2025-03-12 19:51 ` Dave Chinner
2025-03-12 21:00 ` John Garry
2025-03-06 8:47 ` (subset) [PATCH v4 00/12] large atomic writes for xfs with CoW Christian Brauner
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=Z84NTP5tyHEVLNbA@dread.disaster.area \
--to=david@fromorbit.com \
--cc=brauner@kernel.org \
--cc=cem@kernel.org \
--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