[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