summaryrefslogtreecommitdiffstats
path: root/fs/btrfs/disk-io.h
diff options
context:
space:
mode:
authorBoris Burkov <boris@bur.io>2020-11-19 00:06:19 +0100
committerDavid Sterba <dsterba@suse.com>2020-12-09 19:16:07 +0100
commit5011139a4718455a6cd6214fd84e6f8500fd3874 (patch)
tree5a598fb85f938c0c3b85eaddfcf4beef84f7cd73 /fs/btrfs/disk-io.h
parentbtrfs: only mark bg->needs_free_space if free space tree is on (diff)
downloadlinux-5011139a4718455a6cd6214fd84e6f8500fd3874.tar.xz
linux-5011139a4718455a6cd6214fd84e6f8500fd3874.zip
btrfs: create free space tree on ro->rw remount
When a user attempts to remount a btrfs filesystem with 'mount -o remount,space_cache=v2', that operation silently succeeds. Unfortunately, this is misleading, because the remount does not create the free space tree. /proc/mounts will incorrectly show space_cache=v2, but on the next mount, the file system will revert to the old space_cache. For now, we handle only the easier case, where the existing mount is read-only and the new mount is read-write. In that case, we can create the free space tree without contending with the block groups changing as we go. Reviewed-by: Josef Bacik <josef@toxicpanda.com> Signed-off-by: Boris Burkov <boris@bur.io> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
Diffstat (limited to 'fs/btrfs/disk-io.h')
0 files changed, 0 insertions, 0 deletions