Files
apfstests/tests/btrfs
Qu Wenruo 88231c0c0b btrfs: make sure btrfs can handle full fs trim correctly
Ancient commit f4c697e6406d ("btrfs: return EINVAL if start >
total_bytes in fitrim ioctl") introduced a regression where btrfs
may fail to trim any free space in existing block groups.

It's caused by confusion with btrfs_super_block->total_bytes and
btrfs logical address space.

Unlike physical address, any aligned bytenr in range [0, U64_MAX) is
valid in btrfs logical address space, and it's chunk mapping
mechanism of btrfs to handle the logical<->physical mapping.

The test case will craft a btrfs with the following features:
0) Single data/meta profile
   Make trimmed bytes reporting and chunk allocation more predictable.

1) All chunks start beyond super_block->total_bytes (1G)
   By relocating these blocks several times.

2) Unallocated space is less than 50% of the whole fs

3) Fragmented data chunks
   Data chunks will be full of fragments, 50% of data chunks will be
   free space.

So in theory fstrim should be able to trim over 50% space of the fs.
(after fix, 64% of the fs can be trimmed)

While the regression makes btrfs only able to trim unallocated
space, which is less than 50% of the total space.
(without fix, it's only 31%)

Fixed by patch named "btrfs: Ensure btrfs_trim_fs can trim the whole
fs".

Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
2017-12-01 16:51:00 +08:00
..
2017-02-07 12:15:33 +08:00
2017-04-24 18:01:33 +08:00
2016-02-19 10:49:17 +11:00
2017-02-07 12:15:33 +08:00
2013-10-12 19:30:19 -05:00
2014-12-12 11:26:15 +11:00
2014-12-12 11:26:15 +11:00
2014-12-12 11:26:15 +11:00
2017-03-13 11:59:04 +08:00
2017-02-07 12:15:33 +08:00
2013-12-03 10:29:29 +11:00
2013-12-03 10:29:31 +11:00
2016-04-05 11:46:12 +10:00
2014-02-03 10:06:14 +11:00
2016-02-19 10:49:17 +11:00
2016-01-11 15:05:20 +11:00
2016-02-19 10:49:17 +11:00
2015-10-14 14:19:34 +11:00
2015-10-14 14:19:34 +11:00
2016-02-19 10:49:17 +11:00
2016-02-19 10:49:17 +11:00
2017-01-27 16:06:12 +08:00
2017-01-27 16:06:12 +08:00
2016-02-19 10:49:17 +11:00
2016-02-19 10:49:17 +11:00
2014-08-13 10:59:59 +10:00
2016-02-19 10:49:17 +11:00
2016-02-19 10:49:17 +11:00
2016-02-19 10:49:17 +11:00
2016-02-19 10:49:17 +11:00
2015-04-01 11:38:40 +11:00
2015-04-01 11:32:01 +11:00
2017-03-31 13:09:27 +08:00
2015-04-01 11:35:44 +11:00
2016-02-19 10:49:17 +11:00
2016-02-19 10:49:17 +11:00
2016-02-19 10:49:17 +11:00
2016-02-19 10:49:17 +11:00
2016-02-19 10:49:17 +11:00
2016-02-19 10:49:17 +11:00
2016-02-19 10:49:17 +11:00
2015-09-21 13:06:18 +10:00
2016-02-19 10:49:17 +11:00
2016-02-19 10:49:17 +11:00
2016-02-19 10:49:17 +11:00
2016-02-19 10:49:17 +11:00
2016-02-19 10:49:17 +11:00
2017-11-03 19:04:49 +08:00
2017-11-03 19:04:49 +08:00
2016-07-19 12:20:43 +08:00
2016-07-19 12:20:43 +08:00
2016-12-28 19:19:03 +08:00
2017-02-15 18:02:15 +08:00
2017-11-16 17:04:03 +08:00
2017-11-15 14:45:24 +08:00
2017-11-15 14:45:24 +08:00