Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

btrfs-progs: docs: improve space cache documentation #571

Closed

Conversation

calestyo
Copy link
Contributor

  • "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 [email protected]

@calestyo
Copy link
Contributor Author

@kdave kdave added the docs Changes in documentation or help text label Jan 17, 2023
@calestyo
Copy link
Contributor Author

@kdave have you had a chance to look at this?

- "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 <[email protected]>
@calestyo calestyo force-pushed the improve-space-cache-documentation branch from e607334 to 7a7049e Compare April 26, 2023 02:24
@calestyo
Copy link
Contributor Author

(rebased on master)

@kdave
Copy link
Owner

kdave commented Apr 26, 2023

"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?"

--clear-space-cache option really deletes all the space structures, i.e. the free space inode or the free space tree. After that mount will pick v2 if the free-space-tree compat bit is set, otherwise v1.

@kdave
Copy link
Owner

kdave commented Apr 26, 2023

"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."

Clear_cache resets the state and allows rebuilding, with nospace_cache the caching is disabled, so when both are used it is a you say. I hope I got it right, it's a maze of various flags and transitions in the state machine of the cache rebuild, but to my best understanding your assumptions are correct.

@kdave
Copy link
Owner

kdave commented Apr 26, 2023

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

Same as for v1, i.e. clear_cache first deletes the tree and later in mount process the free-space-tree feature is checked, if set the tree is rebuilt. With nospace_cache rebuilding and caching would be skipped.

@kdave kdave added this to the v6.3 milestone Apr 26, 2023
@kdave
Copy link
Owner

kdave commented Apr 26, 2023

The changes in this PR seem to be in line with that so I'll apply it. I'm about to release 6.3 so if you have further updates please send it separately. Thanks.

@kdave kdave closed this Apr 26, 2023
kdave pushed a commit that referenced this pull request Apr 26, 2023
- "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.

Pull-request: #571
Signed-off-by: Christoph Anton Mitterer <[email protected]>
Signed-off-by: David Sterba <[email protected]>
kdave pushed a commit that referenced this pull request Apr 26, 2023
- "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.

Pull-request: #571
Signed-off-by: Christoph Anton Mitterer <[email protected]>
Signed-off-by: David Sterba <[email protected]>
@calestyo calestyo deleted the improve-space-cache-documentation branch April 26, 2023 23:25
@calestyo
Copy link
Contributor Author

Uhm... sorry but I think there is still some mess in here:

a)

--clear-space-cache option really deletes all the space structures, i.e. the free space inode or the free space tree. After that mount will pick v2 if the free-space-tree compat bit is set, otherwise v1.

Okay, so

--clear-space-cache v1|v2
completely remove the free space cache of the given version

is IMO fine.
But the part, that on next mount a new space cache will be generated was missing - well not strictly speaking but I think it would be good to have it mentioned for convenience.

Also, moving the stuff about clear_cache from btrfs-check.rst to ch-mount-options.rst is fine.

b) and c)
It wasn't really mentioned for v2 in my old commit, that a rebuild would happen "immediate", also not that for v2 the nospace_cache would prevent it, too.

Also made some further minor improvements (IMO) to structure.

I've made PR #620 with these changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs Changes in documentation or help text
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants