[PATCH] btrfs-progs: update the direct IO behavior notes for version 7.3

Qu Wenruo <[email protected]>
Newsgroups org.kernel.vger.linux-btrfs
Message-ID <ae799abcfe1a52d8cc73f1a43565fa2f558999e5.1782864511.git.wqu@suse.com>
Since v7.3 will use IOMAP_DIO_BOUNCE flag to address the performance
drop of falling back to buffer IO, update the direct IO behavior notes
to avoid confusion.

Signed-off-by: Qu Wenruo <[email protected]>
---
 Documentation/ch-checksumming.rst |  7 ++++++-
 Documentation/ch-compression.rst  | 13 ++++++++-----
 2 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/Documentation/ch-checksumming.rst b/Documentation/ch-checksumming.rst
index 39dc79079aef..8ccdb79e25e4 100644
--- a/Documentation/ch-checksumming.rst
+++ b/Documentation/ch-checksumming.rst
@@ -17,10 +17,15 @@ has a detached checksum stored in the checksum tree.
 
    To avoid this, kernel starting with version 6.14 will force a direct
    write to fall back to buffered, if the inode requires a data checksum.
-   This will bring a small performance penalty. If you require true zero-copy
+   This will bring an observable performance penalty. If you require true zero-copy
    direct writes, then set the ``NODATASUM`` flag for the inode and make
    sure the direct IO buffer is fully aligned to block size.
 
+   The kernel starting with version 7.3 will address the unstable buffer by bouncing
+   the buffer if the inode requires data checksums.
+   Although this is not true zero-copy, it's still better than falling back to buffered,
+   achieving 95% of true zero-copy performance.
+
 There are several checksum algorithms supported. The default and backward
 compatible algorithm is *crc32c*. Since kernel 5.5 there are three more with different
 characteristics and trade-offs regarding speed and strength. The following list
diff --git a/Documentation/ch-compression.rst b/Documentation/ch-compression.rst
index df0ed188faa2..7a53fc5b9832 100644
--- a/Documentation/ch-compression.rst
+++ b/Documentation/ch-compression.rst
@@ -171,17 +171,20 @@ Compatibility
 Compression requires both data checksums and COW, so either *nodatasum* or
 *nodatasum* mount option/inode flag will result in no compression.
 
-Direct IO reads of compressed data will always fallback to buffered reads.
+Direct IO reads of compressed data will always falls back to buffered reads.
 
-Direct IO write behavior depends on the inode flag.
-For inodes with data checksum, direct IO writes always fallback to buffered
-writes, thus can generate compressed data if the mount option/inode flags
-allows that.
+Direct IO write behavior depends on the inode flag and kernel version.
+
+Before v7.3, for inodes with data checksums, direct IO writes always fallback
+to buffered writes, thus can generate compressed data if the mount option/inode
+flags allow that.
 
 For inodes without data checksums, direct IO writes will not populate page cache,
 and since the inode has no data checksums, no compressed data will be generated
 anyway.
 
+Starting with kernel v7.3, no compression is performed, no matter if the inode has data checksums or not.
+
 The compression algorithms have been added over time so the version
 compatibility should be also considered, together with other tools that may
 access the compressed data like bootloaders.
-- 
2.54.0
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.