On Wed, Oct 23, 2019 at 06:52:58PM -0400, Dennis Zhou wrote: > 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. > > Signed-off-by: Dennis Zhou <dennis@xxxxxxxxxx> > --- Reviewed-by: Josef Bacik <josef@xxxxxxxxxxxxxx> Thanks, Josef
