summaryrefslogtreecommitdiffstats
path: root/fs/btrfs/free-space-cache.c
diff options
context:
space:
mode:
authorJosef Bacik <josef@redhat.com>2011-05-27 16:11:38 -0400
committerJosef Bacik <josef@redhat.com>2011-06-08 16:37:29 -0400
commit723bda2083d44edbd6be0f0b09f902120dc07442 (patch)
tree55ee1276c7e5e1dc95a6204cc138d69983bb0ffb /fs/btrfs/free-space-cache.c
parent2cdc342c204dba69ca3b2ec43d8e6ff41ed920b8 (diff)
downloadblackbird-op-linux-723bda2083d44edbd6be0f0b09f902120dc07442.tar.gz
blackbird-op-linux-723bda2083d44edbd6be0f0b09f902120dc07442.zip
Btrfs: fix the allocator loop logic
I was testing with empty_cluster = 0 to try and reproduce a problem and kept hitting early enospc panics. This was because our loop logic was a little confused. So this is what I did 1) Make the loop variable the ultimate decider on wether we should loop again isntead of checking to see if we had an uncached bg, empty size or empty cluster. 2) Increment loop before checking to see what we are on to make the loop definitions make more sense. 3) If we are on the chunk alloc loop don't set empty_size/empty_cluster to 0 unless we didn't actually allocate a chunk. If we did allocate a chunk we should be able to easily setup a new cluster so clearing empty_size/empty_cluster makes us less efficient. This kept me from hitting panics while trying to reproduce the other problem. Thanks, Signed-off-by: Josef Bacik <josef@redhat.com>
Diffstat (limited to 'fs/btrfs/free-space-cache.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud