- 23 Mar, 2020 40 commits
-
-
David Sterba authored
All functions that set up extent_page_data::tree set it to the inode io_tree. That's passed down the callstack that accesses either the same inode or its pages. In the end submit_extent_page can pull the tree out of the page and we don't have to store it in the structure. Reviewed-by:
Anand Jain <anand.jain@oracle.com> Reviewed-by:
Johannes Thumshirn <johannes.thumshirn@wdc.com> Reviewed-by:
Nikolay Borisov <nborisov@suse.com> Signed-off-by:
David Sterba <dsterba@suse.com>
-
David Sterba authored
The status of aborted transaction can change between calls and it needs to be accessed by READ_ONCE. Add a helper that also wraps the unlikely hint. Reviewed-by:
Josef Bacik <josef@toxicpanda.com> Signed-off-by:
-
David Sterba authored
The helpers are related to locking so move them there, update comments. Reviewed-by:
-
Josef Bacik authored
We are now using these for all roots, rename them to btrfs_put_root() and btrfs_grab_root(); Reviewed-by:
-
Josef Bacik authored
Now that we're going to start relying on getting ref counting right for roots, add a list to track allocated roots and print out any roots that aren't freed up at free_fs_info time. Hide this behind CONFIG_BTRFS_DEBUG because this will just be used for developers to verify they aren't breaking things. Reviewed-by:
-
Josef Bacik authored
In adding things like eb leak checking and root leak checking there were a lot of weird corner cases that come from the fact that 1) We do not init the fs_info until we get to open_ctree time in the normal case and 2) The test infrastructure half-init's the fs_info for things that it needs. This makes it really annoying to make changes because you have to add init in two different places, have special cases for testing fs_info's that may not have certain things initialized, and cases for fs_info's that didn't make it to open_ctree and thus are not fully set up. Fix this by extracting out the non-allocating init of the fs info into it's own public function and use that to make sure we're all getting consistent views of an allocated fs_info. Signed-off-by: -
Josef Bacik authored
open_ctree mixes initialization of fs stuff and fs_info stuff, which makes it confusing when doing things like adding the root leak detection. Make a separate function that inits all the static structures inside of the fs_info needed for the fs to operate, and then call that before we start setting up the fs_info to be mounted. Reviewed-by:
-
Josef Bacik authored
Things like the percpu_counters, the mapping_tree, and the csum hash can all be freed at btrfs_free_fs_info time, since the helpers all check if the structure has been initialized already. This significantly cleans up the error cases in open_ctree. Signed-off-by:
-
Josef Bacik authored
Now that all callers of btrfs_get_fs_root are subsequently calling btrfs_grab_fs_root and handling dropping the ref when they are done appropriately, go ahead and push btrfs_grab_fs_root up into btrfs_get_fs_root. Signed-off-by:
-
Josef Bacik authored
If we are going to track leaked roots we need to free them all the same way, so don't kfree() roots directly, use btrfs_put_fs_root. Reviewed-by:
-
Josef Bacik authored
We lookup the fs_root and put it in our fs_info directly, we should hold a ref on this root for the lifetime of the fs_info. Signed-off-by:
-
Josef Bacik authored
We're going to start freeing roots and doing other complicated things in free_fs_info, so we need to move it to disk-io.c and export it in order to use things lik btrfs_put_fs_root(). Reviewed-by:
-
Josef Bacik authored
We lookup the uuid of arbitrary subvolumes, hold a ref on the root while we're doing this. Signed-off-by:
-
Josef Bacik authored
We replay the log into arbitrary fs roots, hold a ref on the root while we're doing this. Signed-off-by:
-
Josef Bacik authored
We create the snapshot and then use it for a bunch of things, we need to hold a ref on it while we're messing with it. Signed-off-by:
-
Josef Bacik authored
We lookup the name of a subvol which means we'll cross into different roots. Hold a ref while we're doing the look ups in the fs_root we're searching. Signed-off-by:
-
Josef Bacik authored
We lookup all the clone roots and the parent root for send, so we need to hold refs on all of these roots while we're processing them. Signed-off-by:
-
Josef Bacik authored
We look up the root for the bytenr that is failing, so we need to hold a ref on the root for that operation. Signed-off-by:
-
Josef Bacik authored
We lookup roots for every orphan item we have, we need to hold a ref on the root while we're doing this work. Signed-off-by:
-
Josef Bacik authored
All of relocation uses read_fs_root to lookup fs roots, so push the btrfs_grab_fs_root() up into that helper and remove the individual calls. Signed-off-by:
-
Josef Bacik authored
We look up the fs root in various places in here when recovering from a crashed relcoation. Make sure we hold a ref on the root whenever we look them up. Signed-off-by:
-
Josef Bacik authored
We're creating a reloc inode in the data reloc tree, we need to hold a ref on the root while we're doing that. Signed-off-by:
-
Josef Bacik authored
We're looking up the data references for the bytenr in a root, we need to hold a ref on that root while we're doing that. Signed-off-by:
-
Josef Bacik authored
We are recording this root in the transaction, so we need to hold a ref on it until we do that. Signed-off-by:
-
Josef Bacik authored
We look up the corresponding root for the reloc root, we need to hold a ref while we're messing with it. Signed-off-by:
-
Josef Bacik authored
We look up the reloc roots corresponding root, we need to hold a ref on that root. Signed-off-by:
-
Josef Bacik authored
This is trickier than the previous conversions. We have backref_node's that need to hold onto their root for their lifetime. Do the read of the root and grab the ref. If at any point we don't use the root we discard it, however if we use it in our backref node we don't free it until we free the backref node. Any time we switch the root's for the backref node we need to drop our ref on the old root and grab the ref on the new root, and if we dupe a node we need to get a ref on the root there as well. Signed-off-by:
-
Josef Bacik authored
We look up an arbitrary fs root here, we need to hold a ref on the root for the duration. Signed-off-by:
-
Josef Bacik authored
We look up whatever root userspace has given us, we need to hold a ref throughout this operation. Use 'root' only for the on fs root and not as a temporary variable elsewhere. Signed-off-by:
-
Josef Bacik authored
We can wander into a different root, so grab a ref on the root we look up. Later on we make root = fs_info->tree_root so we need this separate out label to make sure we do the right cleanup only in the case we're looking up a different root. Signed-off-by:
-
Josef Bacik authored
We look up an arbitrary fs root, we need to hold a ref on it while we're doing our search. Signed-off-by:
-
Josef Bacik authored
We lookup a arbitrary fs root, we need to hold a ref on that root. If we're using our own inodes root then grab a ref on that as well to make the cleanup easier. Signed-off-by:
-
Josef Bacik authored
We're creating the new root here, but we should hold the ref until after we've initialized the inode for it. Signed-off-by:
-
Josef Bacik authored
Looking up the inode from an arbitrary tree means we need to hold a ref on that root. Signed-off-by:
-
Josef Bacik authored
We are looking up an arbitrary inode, we need to hold a ref on the root while we're doing this. Signed-off-by:
-
Josef Bacik authored
Looking up the inode we need to search the root, make sure we hold a reference on that root while we're doing the lookup. Signed-off-by:
-
Josef Bacik authored
We're looking up a random root, we need to hold a ref on it while we're using it. Reviewed-by:
-
Josef Bacik authored
If the root is sitting in the radix tree, we should probably have a ref for the radix tree. Grab a ref on the root when we insert it, and drop it when it gets deleted. Reviewed-by:
-
Josef Bacik authored
Add another comment to cover how the space reservation system works generally. This covers the actual reservation flow, as well as how flushing is handled. Signed-off-by:
-
Josef Bacik authored
delalloc space reservation is tricky because it encompasses both data and metadata. Make it clear what each side does, the general flow of how space is moved throughout the lifetime of a write, and what goes into the calculations. Signed-off-by:
-
