diff options
author | Boris Burkov <boris@bur.io> | 2020-11-19 02:06:22 +0300 |
---|---|---|
committer | David Sterba <dsterba@suse.com> | 2020-12-09 21:16:08 +0300 |
commit | 948462294577a3870c407c16d89bb2314f0b0cfb (patch) | |
tree | 3ef24bbc5ecac9ddc42ea657752d01c6de81947c /certs | |
parent | 8b228324a8ce03083a034dfa784bc10696ce7489 (diff) | |
download | linux-948462294577a3870c407c16d89bb2314f0b0cfb.tar.xz |
btrfs: keep sb cache_generation consistent with space_cache
When mounting, btrfs uses the cache_generation in the super block to
determine if space cache v1 is in use. However, by mounting with
nospace_cache or space_cache=v2, it is possible to disable space cache
v1, which does not result in un-setting cache_generation back to 0.
In order to base some logic, like mount option printing in /proc/mounts,
on the current state of the space cache rather than just the values of
the mount option, keep the value of cache_generation consistent with the
status of space cache v1.
We ensure that cache_generation > 0 iff the file system is using
space_cache v1. This requires committing a transaction on any mount
which changes whether we are using v1. (v1->nospace_cache, v1->v2,
nospace_cache->v1, v2->v1).
Since the mechanism for writing out the cache generation is transaction
commit, but we want some finer grained control over when we un-set it,
we can't just rely on the SPACE_CACHE mount option, and introduce an
fs_info flag that mount can use when it wants to unset the generation.
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Boris Burkov <boris@bur.io>
Signed-off-by: David Sterba <dsterba@suse.com>
Diffstat (limited to 'certs')
0 files changed, 0 insertions, 0 deletions