Skip to content

Commit e9255d6

Browse files
adam900710kdave
authored andcommitted
btrfs: scrub: remove the old scrub recheck code
The old scrub code has different entrance to verify the content, and since we have removed the writeback path, now we can start removing the re-check part, including: - scrub_recover structure - scrub_sector::recover member - function scrub_setup_recheck_block() - function scrub_recheck_block() - function scrub_recheck_block_checksum() - function scrub_repair_block_group_good_copy() - function scrub_repair_sector_from_good_copy() - function scrub_is_page_on_raid56() - function full_stripe_lock() - function search_full_stripe_lock() - function get_full_stripe_logical() - function insert_full_stripe_lock() - function lock_full_stripe() - function unlock_full_stripe() - btrfs_block_group::full_stripe_locks_root member - btrfs_full_stripe_locks_tree structure This infrastructure is to ensure RAID56 scrub is properly handling recovery and P/Q scrub correctly. This is no longer needed, before P/Q scrub we will wait for all the involved data stripes to be scrubbed first, and RAID56 code has internal lock to ensure no race in the same full stripe. - function scrub_print_warning() - function scrub_get_recover() - function scrub_put_recover() - function scrub_handle_errored_block() - function scrub_setup_recheck_block() - function scrub_bio_wait_endio() - function scrub_submit_raid56_bio_wait() - function scrub_recheck_block_on_raid56() - function scrub_recheck_block() - function scrub_recheck_block_checksum() - function scrub_repair_block_from_good_copy() - function scrub_repair_sector_from_good_copy() And two more functions exported temporarily for later cleanup: - alloc_scrub_sector() - alloc_scrub_block() Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
1 parent 16f9399 commit e9255d6

4 files changed

Lines changed: 14 additions & 1012 deletions

File tree

fs/btrfs/block-group.c

Lines changed: 0 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -160,15 +160,6 @@ void btrfs_put_block_group(struct btrfs_block_group *cache)
160160
btrfs_discard_cancel_work(&cache->fs_info->discard_ctl,
161161
cache);
162162

163-
/*
164-
* If not empty, someone is still holding mutex of
165-
* full_stripe_lock, which can only be released by caller.
166-
* And it will definitely cause use-after-free when caller
167-
* tries to release full stripe lock.
168-
*
169-
* No better way to resolve, but only to warn.
170-
*/
171-
WARN_ON(!RB_EMPTY_ROOT(&cache->full_stripe_locks_root.root));
172163
kfree(cache->free_space_ctl);
173164
kfree(cache->physical_map);
174165
kfree(cache);
@@ -2124,8 +2115,6 @@ static struct btrfs_block_group *btrfs_create_block_group_cache(
21242115
btrfs_init_free_space_ctl(cache, cache->free_space_ctl);
21252116
atomic_set(&cache->frozen, 0);
21262117
mutex_init(&cache->free_space_lock);
2127-
cache->full_stripe_locks_root.root = RB_ROOT;
2128-
mutex_init(&cache->full_stripe_locks_root.lock);
21292118

21302119
return cache;
21312120
}

fs/btrfs/block-group.h

Lines changed: 0 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -91,14 +91,6 @@ struct btrfs_caching_control {
9191
/* Once caching_thread() finds this much free space, it will wake up waiters. */
9292
#define CACHING_CTL_WAKE_UP SZ_2M
9393

94-
/*
95-
* Tree to record all locked full stripes of a RAID5/6 block group
96-
*/
97-
struct btrfs_full_stripe_locks_tree {
98-
struct rb_root root;
99-
struct mutex lock;
100-
};
101-
10294
struct btrfs_block_group {
10395
struct btrfs_fs_info *fs_info;
10496
struct inode *inode;
@@ -229,9 +221,6 @@ struct btrfs_block_group {
229221
*/
230222
int swap_extents;
231223

232-
/* Record locked full stripes for RAID5/6 block group */
233-
struct btrfs_full_stripe_locks_tree full_stripe_locks_root;
234-
235224
/*
236225
* Allocation offset for the block group to implement sequential
237226
* allocation. This is used only on a zoned filesystem.

0 commit comments

Comments
 (0)