btrfs: update superblock's device bytes_used when dropping chunk
commit ae4477f937569d097ca5dbce92a89ba384b49bc6 upstream.
Each superblock contains a copy of the device item for that device. In a
transaction which drops a chunk but doesn't create any new ones, we were
correctly updating the device item in the chunk tree but not copying
over the new bytes_used value to the superblock.
This can be seen by doing the following:
# dd if=/dev/zero of=test bs=4096 count=2621440
# mkfs.btrfs test
# mount test /root/temp
# cd /root/temp
# for i in {00..10}; do dd if=/dev/zero of=$i bs=4096 count=32768; done
# sync
# rm *
# sync
# btrfs balance start -dusage=0 .
# sync
# cd
# umount /root/temp
# btrfs check test
For btrfs-check to detect this, you will also need my patch at
https://github.com/kdave/btrfs-progs/pull/991.
Change btrfs_remove_dev_extents() so that it adds the devices to the
fs_info->post_commit_list if they're not there already. This causes
btrfs_commit_device_sizes() to be called, which updates the bytes_used
value in the superblock.
Fixes: bbbf7243d6
("btrfs: combine device update operations during transaction commit")
CC: stable@vger.kernel.org # 5.10+
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Mark Harmstone <maharmstone@fb.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 9052c7bca391bac0598c5f31302313539899a218)
This commit is contained in:
parent
82d353f3ac
commit
1dab14e720
|
@ -3174,6 +3174,12 @@ int btrfs_remove_chunk(struct btrfs_trans_handle *trans, u64 chunk_offset)
|
|||
device->bytes_used - dev_extent_len);
|
||||
atomic64_add(dev_extent_len, &fs_info->free_chunk_space);
|
||||
btrfs_clear_space_info_full(fs_info);
|
||||
|
||||
if (list_empty(&device->post_commit_list)) {
|
||||
list_add_tail(&device->post_commit_list,
|
||||
&trans->transaction->dev_update_list);
|
||||
}
|
||||
|
||||
mutex_unlock(&fs_info->chunk_mutex);
|
||||
}
|
||||
}
|
||||
|
|
Loading…
Reference in New Issue