Btrfs: fix trim 0 bytes after a device delete
A user reported a bug of btrfs's trim, that is we will trim 0 bytes after a device delete. The reproducer: $ mkfs.btrfs disk1 $ mkfs.btrfs disk2 $ mount disk1 /mnt $ fstrim -v /mnt $ btrfs device add disk2 /mnt $ btrfs device del disk1 /mnt $ fstrim -v /mnt This is because after we delete the device, the block group may start from a non-zero place, which will confuse trim to discard nothing. Reported-by: Lutz Euler <lutz.euler@freenet.de> Signed-off-by: Liu Bo <liubo2009@cn.fujitsu.com>
This commit is contained in:
parent
6af021d8fc
commit
2cac13e41b
@ -7886,9 +7886,16 @@ int btrfs_trim_fs(struct btrfs_root *root, struct fstrim_range *range)
|
||||
u64 start;
|
||||
u64 end;
|
||||
u64 trimmed = 0;
|
||||
u64 total_bytes = btrfs_super_total_bytes(fs_info->super_copy);
|
||||
int ret = 0;
|
||||
|
||||
cache = btrfs_lookup_block_group(fs_info, range->start);
|
||||
/*
|
||||
* try to trim all FS space, our block group may start from non-zero.
|
||||
*/
|
||||
if (range->len == total_bytes)
|
||||
cache = btrfs_lookup_first_block_group(fs_info, range->start);
|
||||
else
|
||||
cache = btrfs_lookup_block_group(fs_info, range->start);
|
||||
|
||||
while (cache) {
|
||||
if (cache->key.objectid >= (range->start + range->len)) {
|
||||
|
Loading…
Reference in New Issue
Block a user