diff mbox series

btrfs-progs: docs: improve space cache documentation

Message ID afabf6cea649902733684575037e718f151a2ce1.camel@scientia.org (mailing list archive)
State New, archived
Headers show
Series btrfs-progs: docs: improve space cache documentation | expand

Commit Message

Christoph Anton Mitterer Jan. 16, 2023, 2:07 p.m. UTC
- "Wipe" in storage terms is often understood as some kind of secure deletion.
  Use "remove" instead in order to indicate that the space cache is fully
  removed (and not just cleared and then e.g. automatically rebuild).

- The --clear-space-cache option for btrfs check actually clears the whole space
  cache, just as documented.
  Thus move any documentation about the clear_cache mount option not doing so
  for v1 to that.
  Instead, refer to the mount option.

- Also note that when clear_cache is used with v1, the free space cache for
  block groups that are modified gets always cleared, but rebuilt only if
  nospace_cache is not used.

Signed-off-by: Christoph Anton Mitterer <mail@christoph.anton.mitterer.name>
---
 Documentation/btrfs-check.rst      | 12 ++----------
 Documentation/ch-mount-options.rst | 18 +++++++++++++++---
 2 files changed, 17 insertions(+), 13 deletions(-)

Comments

Christoph Anton Mitterer Jan. 16, 2023, 3:24 p.m. UTC | #1
Hey Qu, Dave.

Since the space cache clearing options remain a source for confusion,
I'd have written the above patch (there's also a draft PR) which tries
to improve the documentation a bit.


What remains open (which why the patch/PR is just a draft) is:

a) Does --clear-space-cache v1|v2 really remove (or just clear) any
   space cache from the fs? Or is there even a difference?
 
   Especially, when I ran --clear-space-cache v1|v2 and then mount the
   fs (without neither nospace_cache nor space_cache[=*])...
   will it automatically get a new space cache, if so, which?

b) Is my assumption correct, that with v1, clear_cache itself really
   only clears the space cache for written blocks but not automatically
   rebuilds it.
   I.e. when clear_cache,nospace_cache would be used, its just cleared
   but not rebuild.

c) What about clear_cache and v2? Is it only clearing? Or is it,
   unless nospace_cache is used, right after clearing completely
   rebuilt?


Cheers,
Chris.
diff mbox series

Patch

diff --git a/Documentation/btrfs-check.rst b/Documentation/btrfs-check.rst
index bca0e7f8..1bd35fe2 100644
--- a/Documentation/btrfs-check.rst
+++ b/Documentation/btrfs-check.rst
@@ -79,17 +79,9 @@  SAFE OR ADVISORY OPTIONS
         superblock is damaged.
 
 --clear-space-cache v1|v2
-        completely wipe all free space cache of given type
+        completely remove the free space cache of the given version
 
-        For free space cache *v1*, the *clear_cache* kernel mount option only rebuilds
-        the free space cache for block groups that are modified while the filesystem is
-        mounted with that option. Thus, using this option with *v1* makes it possible
-        to actually clear the entire free space cache.
-
-        For free space cache *v2*, the *clear_cache* kernel mount option destroys
-        the entire free space cache. This option, with *v2* provides an alternative
-        method of clearing the free space cache that doesn't require mounting the
-        filesystem.
+        See also the *clear_cache* mount option.
 
 --clear-ino-cache
         remove leftover items pertaining to the deprecated inode map feature
diff --git a/Documentation/ch-mount-options.rst b/Documentation/ch-mount-options.rst
index 3536a5bb..c9b64f19 100644
--- a/Documentation/ch-mount-options.rst
+++ b/Documentation/ch-mount-options.rst
@@ -86,8 +86,19 @@  check_int, check_int_data, check_int_print_mask=<value>
         for more information.
 
 clear_cache
-        Force clearing and rebuilding of the disk space cache if something
-        has gone wrong. See also: *space_cache*.
+        Force clearing and rebuilding of the free space cache if something
+        has gone wrong.
+
+        For free space cache *v1*, this only clears (and, unless *nospace_cache* is
+        used, rebuilds) the free space cache for block groups that are modified while
+        the filesystem is mounted with that option. To actually clear an entire free
+        space cache *v1*, see ``btrfs check --clear-space-cache v1``.
+
+        For free space cache *v2*, this clears the entire free space cache.
+        To do so without requiring to mounting the filesystem, see
+         ``btrfs check --clear-space-cache v2``.
+
+        See also: *space_cache*.
 
 commit=<seconds>
         (since: 3.12, default: 30)
@@ -348,7 +359,8 @@  space_cache, space_cache=<version>, nospace_cache
         implementation, which adds a new b-tree called the free space tree, addresses
         this issue. Once enabled, the *v2* space cache will always be used and cannot
         be disabled unless it is cleared. Use *clear_cache,space_cache=v1* or
-        *clear_cache,nospace_cache* to do so. If *v2* is enabled, kernels without *v2*
+        *clear_cache,nospace_cache* to do so. If *v2* is enabled, and *v1* space
+        cache will be cleared (at the first mount) and kernels without *v2*
         support will only be able to mount the filesystem in read-only mode.
 
         The :doc:`btrfs-check(8)<btrfs-check>` and `:doc:`mkfs.btrfs(8)<mkfs.btrfs>` commands have full *v2* free space