diff options
| author | Josef Bacik <josef@redhat.com> | 2009-09-11 16:11:20 -0400 |
|---|---|---|
| committer | Chris Mason <chris.mason@oracle.com> | 2009-09-21 19:23:50 -0400 |
| commit | 25891f796d8d30f2b86b1e84d78721b44d573d70 (patch) | |
| tree | 12d4ac7251006a73e8ae75b3a4a751d04df0e823 /fs/btrfs/extent-tree.c | |
| parent | f61408b81cd040a594dc0b65171230c4d5cc917d (diff) | |
| download | linux-rpi-25891f796d8d30f2b86b1e84d78721b44d573d70.tar.gz linux-rpi-25891f796d8d30f2b86b1e84d78721b44d573d70.tar.bz2 linux-rpi-25891f796d8d30f2b86b1e84d78721b44d573d70.zip | |
Btrfs: fix extent entry threshold calculation
There is a slight problem with the extent entry threshold calculation for the
free space cache. We only adjust the threshold down as we add bitmaps, but
never actually adjust the threshold up as we add bitmaps. This means we could
fragment the free space so badly that we end up using all bitmaps to describe
the free space, use all the free space which would result in the bitmaps being
freed, but then go to add free space again as we delete things and immediately
add bitmaps since the extent threshold would still be 0. Now as we free
bitmaps the extent threshold will be ratcheted up to allow more extent entries
to be added.
Signed-off-by: Josef Bacik <jbacik@redhat.com>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
Diffstat (limited to 'fs/btrfs/extent-tree.c')
0 files changed, 0 insertions, 0 deletions