linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: John Garry <john.g.garry@oracle.com>
To: alx@kernel.org
Cc: linux-man@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	hch@lst.de, djwong@kernel.org, linux-xfs@vger.kernel.org,
	John Garry <john.g.garry@oracle.com>
Subject: [PATCH v3 2/2] statx.2: Add stx_atomic_write_unit_max_opt
Date: Thu, 19 Jun 2025 15:44:55 +0000	[thread overview]
Message-ID: <20250619154455.321848-3-john.g.garry@oracle.com> (raw)
In-Reply-To: <20250619154455.321848-1-john.g.garry@oracle.com>

XFS supports atomic writes - or untorn writes - based on two different
methods:
- HW offload in the disk
- FS method based on out-of-place writes

The value reported in stx_atomic_write_unit_max will be the max size of the
FS-based method.

The max atomic write unit size of the FS-based atomic writes will
typically be much larger than what is capable from the HW offload. However,
FS-based atomic writes will also be typically much slower.

Advertise this HW offload size limit to the user in a new statx member,
stx_atomic_write_unit_max_opt.

We want STATX_WRITE_ATOMIC to get this new member in addition to the
already-existing members, so mention that a value of 0 in
stx_atomic_write_unit_max_opt means that stx_atomic_write_unit_max holds
this optimised limit.

Linux will zero unused statx members, so stx_atomic_write_unit_max_opt
will always hold 0 for older kernel versions which do not support
this FS-based atomic write method (for XFS).

Signed-off-by: John Garry <john.g.garry@oracle.com>
---
 man/man2/statx.2 | 21 ++++++++++++++++++++-
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/man/man2/statx.2 b/man/man2/statx.2
index 273d80711..07ac60b3c 100644
--- a/man/man2/statx.2
+++ b/man/man2/statx.2
@@ -74,6 +74,9 @@ struct statx {
 \&
     /* File offset alignment for direct I/O reads */
     __u32 stx_dio_read_offset_align;
+\&
+    /* Direct I/O atomic write max opt limit */
+    __u32 stx_atomic_write_unit_max_opt;
 };
 .EE
 .in
@@ -266,7 +269,8 @@ STATX_SUBVOL	Want stx_subvol
 	(since Linux 6.10; support varies by filesystem)
 STATX_WRITE_ATOMIC	Want stx_atomic_write_unit_min,
 	stx_atomic_write_unit_max,
-	and stx_atomic_write_segments_max.
+	stx_atomic_write_segments_max,
+	and stx_atomic_write_unit_max_opt.
 	(since Linux 6.11; support varies by filesystem)
 STATX_DIO_READ_ALIGN	Want stx_dio_read_offset_align.
 	(since Linux 6.14; support varies by filesystem)
@@ -514,6 +518,21 @@ is supported on block devices since Linux 6.11.
 The support on regular files varies by filesystem;
 it is supported by xfs and ext4 since Linux 6.13.
 .TP
+.I stx_atomic_write_unit_max_opt
+The maximum size (in bytes) which is
+optimised for writes issued with torn-write protection.
+If non-zero,
+this value will not exceed the value in
+.I stx_atomic_write_unit_max
+and will not be less than the value in
+.IR stx_atomic_write_unit_min .
+A value of zero indicates that
+.I stx_atomic_write_unit_max
+is the optimised limit.
+Slower writes may be experienced when the size of the write exceeds
+.I stx_atomic_write_unit_max_opt
+(when non-zero).
+.TP
 .I stx_atomic_write_segments_max
 The maximum number of elements in an array of vectors
 for a write with torn-write protection enabled.
-- 
2.31.1


  parent reply	other threads:[~2025-06-19 15:45 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-19 15:44 [PATCH v3 0/2] statx.2: Add stx_atomic_write_unit_max_opt John Garry
2025-06-19 15:44 ` [PATCH v3 1/2] statx.2: properly align stx_dio_read_offset_align John Garry
2025-06-23  0:55   ` Alejandro Colomar
2025-06-19 15:44 ` John Garry [this message]
2025-06-23  0:59   ` [PATCH v3 2/2] statx.2: Add stx_atomic_write_unit_max_opt Alejandro Colomar

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=20250619154455.321848-3-john.g.garry@oracle.com \
    --to=john.g.garry@oracle.com \
    --cc=alx@kernel.org \
    --cc=djwong@kernel.org \
    --cc=hch@lst.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-man@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    /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).