Skip to content

Commit 4e19443

Browse files
josefbacikkdave
authored andcommitted
btrfs: free block groups after free'ing fs trees
Sometimes when running generic/475 we would trip the WARN_ON(cache->reserved) check when free'ing the block groups on umount. This is because sometimes we don't commit the transaction because of IO errors and thus do not cleanup the tree logs until at umount time. These blocks are still reserved until they are cleaned up, but they aren't cleaned up until _after_ we do the free block groups work. Fix this by moving the free after free'ing the fs roots, that way all of the tree logs are cleaned up and we have a properly cleaned fs. A bunch of loops of generic/475 confirmed this fixes the problem. CC: [email protected] # 4.9+ Signed-off-by: Josef Bacik <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]>
1 parent 1362089 commit 4e19443

File tree

1 file changed

+9
-2
lines changed

1 file changed

+9
-2
lines changed

fs/btrfs/disk-io.c

Lines changed: 9 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -4030,11 +4030,18 @@ void __cold close_ctree(struct btrfs_fs_info *fs_info)
40304030
invalidate_inode_pages2(fs_info->btree_inode->i_mapping);
40314031
btrfs_stop_all_workers(fs_info);
40324032

4033-
btrfs_free_block_groups(fs_info);
4034-
40354033
clear_bit(BTRFS_FS_OPEN, &fs_info->flags);
40364034
free_root_pointers(fs_info, true);
40374035

4036+
/*
4037+
* We must free the block groups after dropping the fs_roots as we could
4038+
* have had an IO error and have left over tree log blocks that aren't
4039+
* cleaned up until the fs roots are freed. This makes the block group
4040+
* accounting appear to be wrong because there's pending reserved bytes,
4041+
* so make sure we do the block group cleanup afterwards.
4042+
*/
4043+
btrfs_free_block_groups(fs_info);
4044+
40384045
iput(fs_info->btree_inode);
40394046

40404047
#ifdef CONFIG_BTRFS_FS_CHECK_INTEGRITY

0 commit comments

Comments
 (0)