- 23 Mar, 2020 40 commits
-
-
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 <josef@toxicpanda.com> Reviewed-by:
David Sterba <dsterba@suse.com> 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:
Nikolay Borisov <nborisov@suse.com> Signed-off-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:
-
Josef Bacik authored
This is a giant comment at the top of block-rsv.c describing generally how block reserves work. It is purely about the block reserves themselves, and nothing to do with how the actual reservation system works. Signed-off-by:
-
Josef Bacik authored
We want to use this for dropping all roots, and in some error cases we may not have a root, so handle this to make the cleanup code easier. Make btrfs_grab_fs_root the same so we can use it in cases where the root may not exist (like the quota root). Reviewed-by:
-
Josef Bacik authored
Now that the orphan cleanup stuff doesn't use this directly we can just make them static. Reviewed-by:
-
Josef Bacik authored
All this does is call btrfs_get_fs_root() with check_ref == true. Just use btrfs_get_fs_root() so we don't have a bunch of different helpers that do the same thing. Reviewed-by:
-
Josef Bacik authored
All helpers should either be using btrfs_get_fs_root() or btrfs_read_tree_root(). Reviewed-by:
-
Josef Bacik authored
Relocation has it's special roots, we don't want to save these in the root cache either, so swap it to use btrfs_read_tree_root(). However the reloc root does need REF_COWS set, so make sure we set it everywhere we use this helper, as it no longer does the REF_COWS setting. Reviewed-by:
-
Josef Bacik authored
Tree-log uses btrfs_read_fs_root to load its log, but this just calls btrfs_read_tree_root. We don't save the log roots in our root cache, so just export this helper and use it in the logging code. Reviewed-by:
-
Josef Bacik authored
btrfs_find_orphan_roots has this weird thing where it looks up the root in cache to see if it is there before just reading the root. But the read it uses just reads the root, it doesn't do any of the init work, we do that by hand here. But this is unnecessary, all we really want is to see if the root still exists and add it to the dead roots list to be cleaned up, otherwise we delete the orphan item. Fix this by just using btrfs_get_fs_root directly with check_ref set to false so we get the orphan root items. Then we just handle in cache and out of cache roots the same, add them to the dead roots list and carry on. Reviewed-by:
-
Josef Bacik authored
We have a helper for reading fs roots that just reads the fs root off the disk and then sets REF_COWS and init's the inheritable flags. Move this into btrfs_init_fs_root so we can later get rid of this helper and consolidate all of the fs root reading into one helper. Reviewed-by:
-
Josef Bacik authored
There's no reason to not init the root at alloc time, and with later patches it actually causes problems if we error out mounting the fs before the tree_root is init'ed because we expect it to have a valid ref count. Fix this by pushing __setup_root into btrfs_alloc_root. Reviewed-by:
-
Josef Bacik authored
Now that we have a safe way to update the isize, remove all of this code as it's no longer needed. Reviewed-by:
Filipe Manana <fdmanana@suse.com> Signed-off-by:
-
Josef Bacik authored
Now that we have a safe way to update the i_size, replace all uses of btrfs_ordered_update_i_size with btrfs_inode_safe_disk_i_size_write. Reviewed-by:
-
Josef Bacik authored
We want to use this everywhere we modify the file extent items permanently. These include: 1) Inserting new file extents for writes and prealloc extents. 2) Truncating inode items. 3) btrfs_cont_expand(). 4) Insert inline extents. 5) Insert new extents from log replay. 6) Insert a new extent for clone, as it could be past i_size. 7) Hole punching For hole punching in particular it might seem it's not necessary because anybody extending would use btrfs_cont_expand, however there is a corner that still can give us trouble. Start with an empty file and fallocate KEEP_SIZE 1M-2M We now have a 0 length file, and a hole file extent from 0-1M, and a prealloc extent from 1M-2M. Now punch 1M-1.5M Because this is past i_size we have [HOLE EXTENT][ NOTHING ][PREALLOC] [0 1M][1M 1.5M][1.5M 2M] with an i_size of 0. Now if we pwrite 0-1.5M we'll increas our i_size to 1.5M, but our disk_i_size is still 0 until the ordered extent completes. However if we now immediately truncate 2M on the file we'll just call btrfs_cont_expand(inode, 1.5M, 2M), since our old i_size is 1.5M. If we commit the transaction here and crash we'll expose the gap. To fix this we need to clear the file extent mapping for the range that we punched but didn't insert a corresponding file extent for. This will mean the truncate will only get an disk_i_size set to 1M if we crash before the finish ordered io happens. I've written an xfstest to reproduce the problem and validate this fix. Reviewed-by:
-
Josef Bacik authored
In order to keep track of where we have file extents on disk, and thus where it is safe to adjust the i_size to, we need to have a tree in place to keep track of the contiguous areas we have file extents for. Add helpers to use this tree, as it's not required for NO_HOLES file systems. We will use this by setting DIRTY for areas we know we have file extent item's set, and clearing it when we remove file extent items for truncation. Reviewed-by:
-
Josef Bacik authored
We were using btrfs_i_size_write(), which unconditionally jacks up inode->disk_i_size. However since clone can operate on ranges we could have pending ordered extents for a range prior to the start of our clone operation and thus increase disk_i_size too far and have a hole with no file extent. Fix this by using the btrfs_ordered_update_i_size helper which will do the right thing in the face of pending ordered extents outside of our clone range. Reviewed-by:
-
Su Yue authored
Btrfsctl was removed in 2012, now the function btrfs_control_ioctl() is only used for devices ioctls. So update the comment. Reviewed-by:
Su Yue <Damenly_Su@gmx.com> Reviewed-by:
-
Qu Wenruo authored
Relocation is one of the most complex part of btrfs, while it's also the foundation stone for online resizing, profile converting. For such a complex facility, we should at least have some introduction to it. This patch will add an basic introduction at pretty a high level, explaining: - What relocation does - How relocation is done Only mentioning how data reloc tree and reloc tree are involved in the operation. No details like the backref cache, or the data reloc tree contents. - Which function to refer. More detailed comments will be added for reloc tree creation, data reloc tree creation and backref cache. Signed-off-by:
Qu Wenruo <wqu@suse.com> Reviewed-by:
-
