]> asedeno.scripts.mit.edu Git - linux.git/commit
btrfs: keep track of free space bitmap trim status cleanliness
authorDennis Zhou <dennis@kernel.org>
Sat, 14 Dec 2019 00:22:13 +0000 (16:22 -0800)
committerDavid Sterba <dsterba@suse.com>
Mon, 20 Jan 2020 15:40:57 +0000 (16:40 +0100)
commitda080fe1bad4777b02f6a3db42823a8797aadbca
tree3d7f540dee2b6dfd8a188d34ceb2fa8a9fd2412b
parenta7ccb255852413dd59263e551fd0ef13f76fc9b9
btrfs: keep track of free space bitmap trim status cleanliness

There is a cap in btrfs in the amount of free extents that a block group
can have. When it surpasses that threshold, future extents are placed
into bitmaps. Instead of keeping track of if a certain bit is trimmed or
not in a second bitmap, keep track of the relative state of the bitmap.

With async discard, trimming bitmaps becomes a more frequent operation.
As a trade off with simplicity, we keep track of if discarding a bitmap
is in progress. If we fully scan a bitmap and trim as necessary, the
bitmap is marked clean. This has some caveats as the min block size may
skip over regions deemed too small. But this should be a reasonable
trade off rather than keeping a second bitmap and making allocation
paths more complex. The downside is we may overtrim, but ideally the min
block size should prevent us from doing that too often and getting stuck
trimming pathological cases.

BTRFS_TRIM_STATE_TRIMMING is added to indicate a bitmap is in the
process of being trimmed. If additional free space is added to that
bitmap, the bit is cleared. A bitmap will be marked
BTRFS_TRIM_STATE_TRIMMED if the trimming code was able to reach the end
of it and the former is still set.

Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Dennis Zhou <dennis@kernel.org>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
fs/btrfs/free-space-cache.c
fs/btrfs/free-space-cache.h