mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: John Garry <john.g.garry@oracle.com>
To: alx@kernel.org, brauner@kernel.org, djwong@kernel.org,
	dchinner@redhat.com, hch@lst.de
Cc: linux-man@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-xfs@vger.kernel.org, linux-kernel@vger.kernel.org,
	ojaswin@linux.ibm.com, ritesh.list@gmail.com,
	martin.petersen@oracle.com, John Garry <john.g.garry@oracle.com>
Subject: [PATCH RFC] statx.2: Add stx_atomic_write_unit_max_opt
Date: Wed, 19 Mar 2025 11:44:02 +0000	[thread overview]
Message-ID: <20250319114402.3757248-1-john.g.garry@oracle.com> (raw)

XFS supports atomic writes - or untorn writes - based on different methods:
- HW offload in the disk
- Software emulation

The value reported in stx_atomic_write_unit_max will be the max of the
software emulation method.

The max atomic write unit size of the software emulated atomic writes will
generally be much larger than the HW offload. However, software emulated
atomic writes will also be typically much slower.

The filesystem will transparently support both methods, specifically
HW offload is the preferred method when possible, e.g. if write size is
small enough then HW offload will be used.

Advertise this HW offload 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 means that
stx_atomic_write_unit_max holds this limit.

Signed-off-by: John Garry <john.g.garry@oracle.com>
---
I'm sending as an RFC as I am not sure if we need bother with this.

Maybe it's better to update the man page to mention that software
emulated atomic writes are available, and the user should check the
mounted bdev atomic write limits instead to know this opt limit.
diff --git a/man/man2/statx.2 b/man/man2/statx.2
index 0abac75c1..c3872f05d 100644
--- a/man/man2/statx.2
+++ b/man/man2/statx.2
@@ -79,6 +79,9 @@ struct statx {
 \&
     /* File offset alignment for direct I/O reads */
     __u32   stx_dio_read_offset_align;
+\&
+    /* Direct I/O atomic write opt max limit */
+    __u32 stx_atomic_write_unit_max_opt;
 };
 .EE
 .in
@@ -271,7 +274,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)
@@ -519,6 +523,15 @@ 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 fast
+untorn writes.
+This value must not exceed the value in
+.I stx_atomic_write_unit_max.
+A value of 0 indicates that
+.I stx_atomic_write_unit_max
+is the optimised limit.
+.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


             reply	other threads:[~2025-03-19 11:45 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-19 11:44 John Garry [this message]
2025-03-20  7:00 ` Christoph Hellwig
2025-03-20  9:19   ` John Garry
2025-03-20 14:12     ` Christoph Hellwig
2025-03-21 10:20       ` John Garry
2025-03-23  6:40         ` Christoph Hellwig
2025-04-03 15:07           ` John Garry
2025-04-04  9:06             ` Christoph Hellwig
2025-04-04  9:23               ` John Garry
2025-04-07  6:51                 ` Christoph Hellwig

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=20250319114402.3757248-1-john.g.garry@oracle.com \
    --to=john.g.garry@oracle.com \
    --cc=alx@kernel.org \
    --cc=brauner@kernel.org \
    --cc=dchinner@redhat.com \
    --cc=djwong@kernel.org \
    --cc=hch@lst.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-man@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=ojaswin@linux.ibm.com \
    --cc=ritesh.list@gmail.com \
    /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

all inboxes | Powered by JetHome®