From: John Garry <john.g.garry@oracle.com>
To: linux-kernel@vger.kernel.org, linux-api@vger.kernel.org
Cc: martin.petersen@oracle.com, djwong@kernel.org,
david@fromorbit.com, himanshu.madhani@oracle.com,
John Garry <john.g.garry@oracle.com>
Subject: [PATCH 3/4] man2/open.2: Document RWF_ATOMIC
Date: Fri, 29 Sep 2023 09:37:16 +0000 [thread overview]
Message-ID: <20230929093717.2972367-4-john.g.garry@oracle.com> (raw)
In-Reply-To: <20230929093717.2972367-1-john.g.garry@oracle.com>
Document special rule when using RWF_ATOMIC flag in conjunction with
O_DIRECT (which is the only time which it can be used).
Some block devices have a virtual boundary, which is a boundary at which
write iovec vectors start and end addresses need to align to - see
virt_boundary_mask in linux kernel sysfs-block Doc.
To avoid splitting writes with torn-write protection in the kernel for
when vectors cross this boundary, special iovec boundary rules are added
such that we don't cross this boundary.
Even though a virt_boundary_mask may be larger than the CPU page size,
we just impose that as a reasonable limit, which matches what the linux
kernel NVMe driver uses today - NVMe is of special interest for supporting
RWF_ATOMIC.
Signed-off-by: John Garry <john.g.garry@oracle.com>
---
man2/open.2 | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/man2/open.2 b/man2/open.2
index 4c921723c95c..e5b9d107859a 100644
--- a/man2/open.2
+++ b/man2/open.2
@@ -1782,6 +1782,19 @@ blockdev \-\-getss
.EE
.in
.PP
+When
+.B O_DIRECT
+is used in conjunction with
+.BR pwritev2 ()
+and
+.BR RWF_ATOMIC
+flag, in addition to any alignment rules already imposed by the filesystem and
+underlying block device, it must be ensured that
+.I iovec
+vectors have no gaps such that the end alignment of a vector must have the same
+start alignment of any subsequent vector and that alignment must be least
+at a page boundary.
+.PP
.B O_DIRECT
I/Os should never be run concurrently with the
.BR fork (2)
--
2.31.1
next prev parent reply other threads:[~2023-09-29 9:38 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-29 9:37 [PATCH 0/4] man2: Document RWF_ATOMIC John Garry
2023-09-29 9:37 ` [PATCH 1/4] statx.2: Document STATX_WRITE_ATOMIC John Garry
2023-09-29 9:37 ` [PATCH 2/4] readv.2: Document RWF_ATOMIC flag John Garry
2023-10-03 19:25 ` Bart Van Assche
2023-10-04 8:47 ` John Garry
2023-10-04 17:36 ` Bart Van Assche
2023-10-04 22:48 ` Dave Chinner
2023-10-09 17:44 ` Darrick J. Wong
2023-10-09 20:39 ` Dave Chinner
2023-10-09 21:05 ` Darrick J. Wong
2023-10-24 12:35 ` John Garry
2023-10-24 15:39 ` Darrick J. Wong
2023-10-24 12:30 ` John Garry
2023-10-24 15:39 ` Darrick J. Wong
2023-09-29 9:37 ` John Garry [this message]
2023-09-29 9:37 ` [PATCH 4/4] io_submit.2: Document RWF_ATOMIC John Garry
2023-10-09 17:45 ` Darrick J. Wong
2023-10-24 11:51 ` 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=20230929093717.2972367-4-john.g.garry@oracle.com \
--to=john.g.garry@oracle.com \
--cc=david@fromorbit.com \
--cc=djwong@kernel.org \
--cc=himanshu.madhani@oracle.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.petersen@oracle.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 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.