Skip to content

Commit 60efeb9

Browse files
jimiskdave
authored andcommitted
btrfs-progs: docs: clarify compress-force mount option
Even with compress-force mount option, btrfs can still fallback to uncompressed write if the block can not be compressed. Add such clarification to avoid confusion. Signed-off-by: Dimitrios Apostolou <jimis@gmx.net> [ Add a proper commit message and SoB line. ] Signed-off-by: Qu Wenruo <wqu@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
1 parent c1a82de commit 60efeb9

File tree

1 file changed

+5
-4
lines changed

1 file changed

+5
-4
lines changed

Documentation/ch-compression.rst

Lines changed: 5 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -104,10 +104,11 @@ Incompressible data
104104
Files with already compressed data or with data that won't compress well with
105105
the CPU and memory constraints of the kernel implementations are using a simple
106106
decision logic. If the first portion of data being compressed is not smaller
107-
than the original, the compression of the file is disabled -- unless the
108-
filesystem is mounted with *compress-force*. In that case compression will
109-
always be attempted on the file only to be later discarded. This is not optimal
110-
and subject to optimizations and further development.
107+
than the original, the compression of the whole file is disabled. Unless the
108+
filesystem is mounted with *compress-force* in which case btrfs will try
109+
compressing every block, falling back to storing the uncompressed version for
110+
each block that ends up larger after compression. This is not optimal and
111+
subject to optimizations and further development.
111112

112113
If a file is identified as incompressible, a flag is set (*NOCOMPRESS*) and it's
113114
sticky. On that file compression won't be performed unless forced. The flag

0 commit comments

Comments
 (0)