- 09 Sep, 2019 40 commits
-
-
David Sterba authored
Signed-off-by:David Sterba <dsterba@suse.com>
-
David Sterba authored
The kobject should be pulled in via sysfs.h and that needs to include it because it needs various definitions like kobj_attribute or kobject. Signed-off-by: -
David Sterba authored
Wrap the fsid renaming code and move it to sysfs.c. Signed-off-by: -
David Sterba authored
The helpers to create block group and space info directories already live in sysfs.c, move the deletion part there too. Signed-off-by: -
David Sterba authored
The device uevent belongs to the sysfs API. Signed-off-by: -
David Sterba authored
In order to unexport the feature type array, add a helper for the enum-to-string conversion. Signed-off-by: -
David Sterba authored
The last non-sysfs usage of space_info_ktype has been moved to a private helper in previous patch so the variable can be made static. Signed-off-by: -
David Sterba authored
Move creation of data/metadata/system space info directories to sysfs.c. Signed-off-by: -
David Sterba authored
The last non-sysfs usage of btrfs_raid_ktype has been moved to a private helper in previous patch so the variable can be made static. Signed-off-by: -
David Sterba authored
The part of link_block_group that just creates the sysfs object is independent and can be factored out to a helper. Signed-off-by: -
David Sterba authored
As the header for sysfs code already exists, use it to clean up ctree.h. Signed-off-by: -
Anand Jain authored
__btrfs_reset_dev_stats() is a small helper function to reset devices stat values, and is used only once, instead just open code it. Signed-off-by:
Anand Jain <anand.jain@oracle.com> Reviewed-by:
-
Anand Jain authored
btrfs_dev_stat_reset() is an overdo in terms of wrapping. So this patch open codes btrfs_dev_stat_reset(). Signed-off-by:
-
Qu Wenruo authored
When we try to delete qgroups, we're pretty cautious, we make sure both qgroups exist and there is a relationship between them, then try to delete the relation. This behavior is OK, but the problem is we need to two relation items, and if we failed the first item deletion, we error out, leaving the other relation item in qgroup tree. Sometimes the error from del_qgroup_relation_item() could just be -ENOENT, thus we can ignore that error and continue without any problem. Further more, such cautious behavior makes qgroup relation deletion impossible for orphan relation items. This patch will enhance __del_qgroup_relation(): - If both qgroups and their relation items exist Go the regular deletion routine and update their accounting if needed. - If any qgroup or relation item doesn't exist Then we still try to delete the orphan items anyway, but don't trigger the accounting update. By this, we try our best to remove relation items, and can handle orphan relation items properly, while still keep the existing behavior for good qgroup tree. Reported-by:
Andrei Borzenkov <arvidjaar@gmail.com> Signed-off-by:
Qu Wenruo <wqu@suse.com> Signed-off-by:
-
Hans van Kranenburg authored
In commit c11d2c23 ("Btrfs: add ioctl to get and reset the device stats") the get_dev_stats ioctl was added. Shortly thereafter, in commit b27f7c0c ("btrfs: join DEV_STATS ioctls to one") , the flags field was added. However, the calculation for unused padding space was not updated, which also invalidated the comment. Clarify what happened to reduce confusion and wasted time for anyone implementing this. Signed-off-by:
Hans van Kranenburg <hans.van.kranenburg@mendix.com> Reviewed-by:
-
Filipe Manana authored
If any call to find_first_clear_extent_bit() returns an unexpected result, the test should fail and not just print an error message, otherwise it makes detection of regressions much harder to notice. Fixes: 1eaebb34 ("btrfs: Don't trim returned range based on input value in find_first_clear_extent_bit") Reviewed-by:
Nikolay Borisov <nborisov@suse.com> Signed-off-by:
Filipe Manana <fdmanana@suse.com> Signed-off-by:
-
Filipe Manana authored
The test creates an extent io tree and sets several ranges with the CHUNK_ALLOCATED and CHUNK_TRIMMED bits, resulting in the allocation of several extent state structures. However the test never clears those ranges, resulting in memory leaks of the extent state structures. This is detected when CONFIG_BTRFS_DEBUG is set once we remove the btrfs module (rmmod btrfs): [57399.787918] BTRFS: state leak: start 67108864 end 75497471 state 1 in tree 1 refs 1 [57399.790155] BTRFS: state leak: start 33554432 end 67108863 state 33 in tree 1 refs 1 [57399.791941] BTRFS: state leak: start 1048576 end 4194303 state 33 in tree 1 refs 1 [57399.793753] BTRFS: state leak: start 67108864 end 75497471 state 1 in tree 1 refs 1 [57399.795188] BTRFS: state leak: start 33554432 end 67108863 state 33 in tree 1 refs 1 [57399.796453] BTRFS: state leak: start 1048576 end 4194303 state 33 in tree 1 refs 1 [57399.797765] BTRFS: state leak: start 67108864 end 75497471 state 1 in tree 1 refs 1 [57399.799049] BTRFS: state leak: start 33554432 end 67108863 state 33 in tree 1 refs 1 [57399.800142] BTRFS: state leak: start 1048576 end 4194303 state 33 in tree 1 refs 1 [57399.801126] BTRFS: state leak: start 67108864 end 75497471 state 1 in tree 1 refs 1 [57399.802106] BTRFS: state leak: start 33554432 end 67108863 state 33 in tree 1 refs 1 [57399.803119] BTRFS: state leak: start 1048576 end 4194303 state 33 in tree 1 refs 1 [57399.804153] BTRFS: state leak: start 67108864 end 75497471 state 1 in tree 1 refs 1 [57399.805196] BTRFS: state leak: start 33554432 end 67108863 state 33 in tree 1 refs 1 [57399.806191] BTRFS: state leak: start 1048576 end 4194303 state 33 in tree 1 refs 1 The start and end offsets reported correspond exactly to the ranges used by the test. So fix that by clearing all the ranges when the test finishes. Fixes: 1eaebb34 ("btrfs: Don't trim returned range based on input value in find_first_clear_extent_bit") Signed-off-by:
-
David Sterba authored
Replaced by the sysfs exports that provide a more fine grained interface for filesystem debugging. Signed-off-by: -
David Sterba authored
Add 'debug' directories to global sysfs and per-filesystem. This will replace the debugfs directory. The sysfs location is simpler and builds on top of the existing file hierarchy so there will hopefully be no more questions about the sample debugfs file. The directory is called 'debug' and only present under CONFIG_BTRFS_DEBUG so this will not affect productions builds. Signed-off-by: -
Josef Bacik authored
extent-tree.c has a find_next_key that just walks up the path to find the next key, but it is used for both the caching stuff and the snapshot delete stuff. The snapshot deletion stuff is special so it can't really use btrfs_find_next_key, but the caching thread stuff can. We just need to fix btrfs_find_next_key to deal with ->skip_locking and then it works exactly the same as the private find_next_key helper. Signed-off-by:
Josef Bacik <josef@toxicpanda.com> Signed-off-by:
-
Josef Bacik authored
This is used in caching and reading block groups, so export it while we move these chunks independently. Signed-off-by:
-
Josef Bacik authored
Man a lot of people use this stuff. Signed-off-by:
-
Josef Bacik authored
We'll need this to move the caching stuff around. Signed-off-by:
-
Josef Bacik authored
This will make it so we can move them easily. Signed-off-by:
-
Josef Bacik authored
These are relatively straightforward as well. Signed-off-by:
-
Josef Bacik authored
Another easy set to move over to block-group.c. Signed-off-by:
-
Josef Bacik authored
Move these bits first as they are the easiest to move. Export two of the helpers so they can be moved all at once. Signed-off-by:
-
Josef Bacik authored
This is prep work for moving all of the block group cache code into its own file. Signed-off-by:
-
Josef Bacik authored
This is prep work for moving block_group_cache around. Having this in the header file makes the header file include need to be in a certain order, which is awkward, so just move it into free-space-cache.c and then we can re-arrange later. Signed-off-by:
-
David Sterba authored
Reviewed-by:
-
David Sterba authored
Reviewed-by:
-
David Sterba authored
Used only for in-memory state tracking. Reviewed-by:
-
David Sterba authored
The switch to open coded set/get has happend long time ago in 962a298f ("btrfs: kill the key type accessor helpers"), remove the stray helpers. Reviewed-by:
-
David Sterba authored
The status of flush bio is tracked as a status bit, changed in commit 1c3063b6 ("btrfs: cleanup device states define BTRFS_DEV_STATE_FLUSH_SENT"), the flush_bio_sent was forgotten. Reviewed-by:
-
Filipe Manana authored
The bulk of the work done when cloning extents, at ioctl.c:btrfs_clone(), is done inside an if statement that checks if the found key has the type BTRFS_EXTENT_DATA_KEY. That if statement is redundant however, because btrfs_search_slot() always leaves us in a leaf slot that points to a key that is always greater then or equals to the search key, and our search key here has that type, and because we bail out before that if statement if the key at the given leaf slot is greater then BTRFS_EXTENT_DATA_KEY. Therefore just remove that if statement, not only because it is useless but mostly because it increases the nesting/indentation level in this function which is quite big and makes things a bit awkward whenever I need to fix something that requires changing btrfs_clone() (and it has been like that for many years already). Signed-off-by:
-
Nikolay Borisov authored
Simplify the code by removing variables that don't bring any real value as well as simplifying the checks when buidling the candidate list of devices. No functional changes. Signed-off-by:
-
Nikolay Borisov authored
join_running_log_trans checks btrfs_root::log_root outside of btrfs_root::log_mutex to avoid contention on the mutex. Turns out this check is not necessary because the two callers of join_running_log_trans (both of which deal with removing entries from the tree-log during unlink) explicitly check whether the respective inode has been logged in the current transaction. If it hasn't then it won't have any items in the tree-log and call path will return before calling join_running_log_trans. If the check passes, however, then it's guaranteed that btrfs_root::log_root is set because the inode is logged. Those guarantees allows us to remove the speculative as well as the implicity and tricky memory barrier. Reviewed-by:
-
Filipe Manana authored
If we need to start an inode caching thread, because none currently exists on disk, we can wake up all waiters as soon as we mark the range starting at root's highest objectid + 1 and ending at BTRFS_LAST_FREE_OBJECTID as free, so that they don't need to wait for the caching thread to start and do some progress. We follow the same approach within the caching thread, since as soon as it finds a free range and marks it as free space in the cache, it wakes up all waiters. So improve this by adding such a wakeup call after marking that initial range as free space. Fixes: a47d6b70 ("Btrfs: setup free ino caching in a more asynchronous way") Reviewed-by:
-
Filipe Manana authored
If the caching thread fails to allocate a path, it returns without waking up any cache waiters, leaving them hang forever. Fix this by following the same approach as when we fail to start the caching thread: print an error message, disable inode caching and make the wakers fallback to non-caching mode behaviour (calling btrfs_find_free_objectid()). Fixes: 581bb050 ("Btrfs: Cache free inode numbers in memory") Reviewed-by:
-
Filipe Manana authored
If we fail to start the inode caching thread, we print an error message and disable the inode cache, however we never wake up any waiters, so they hang forever waiting for the caching to finish. Fix this by waking them up and have them fallback to a call to btrfs_find_free_objectid(). Fixes: e60efa84 ("Btrfs: avoid triggering bug_on() when we fail to start inode caching task") Reviewed-by:
-
