-
Notifications
You must be signed in to change notification settings - Fork 243
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
Conversation
See open questions at: |
@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]>
e607334
to
7a7049e
Compare
(rebased on master) |
"a) Does --clear-space-cache v1|v2 really remove (or just clear) any Especially, when I ran --clear-space-cache v1|v2 and then mount the --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. |
"b) Is my assumption correct, that with v1, clear_cache itself really 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. |
"c) What about clear_cache and v2? Is it only clearing? Or is it, 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. |
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. |
- "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]>
- "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]>
Uhm... sorry but I think there is still some mess in here: a)
Okay, so btrfs-progs/Documentation/btrfs-check.rst Lines 81 to 82 in 405f4c7
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 b) and c) Also made some further minor improvements (IMO) to structure. I've made PR #620 with these changes. |
"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]