aboutsummaryrefslogtreecommitdiffstats
path: root/fs/btrfs/extent-tree.c
diff options
context:
space:
mode:
authorJosef Bacik <josef@redhat.com>2011-05-27 14:07:49 -0400
committerJosef Bacik <josef@redhat.com>2011-06-08 16:37:28 -0400
commit2cdc342c204dba69ca3b2ec43d8e6ff41ed920b8 (patch)
treee077a03c0b17799150b837deeffb27f3842be536 /fs/btrfs/extent-tree.c
parentf2bb8f5cfb3bce595b2de251ed7638047fc4e530 (diff)
downloadkernel_samsung_smdk4412-2cdc342c204dba69ca3b2ec43d8e6ff41ed920b8.zip
kernel_samsung_smdk4412-2cdc342c204dba69ca3b2ec43d8e6ff41ed920b8.tar.gz
kernel_samsung_smdk4412-2cdc342c204dba69ca3b2ec43d8e6ff41ed920b8.tar.bz2
Btrfs: fix bitmap regression
In cleaning up the clustering code I accidently introduced a regression by adding bitmap entries to the cluster rb tree. The problem is if we've maxed out the number of bitmaps we can have for the block group we can only add free space to the bitmaps, but since the bitmap is on the cluster we can't find it and we try to create another one. This would result in a panic because the total bitmaps was bigger than the max bitmaps that were allowed. This patch fixes this by checking to see if we have a cluster, and then looking at the cluster rb tree to see if it has a bitmap entry and if it does and that space belongs to that bitmap, go ahead and add it to that bitmap. I could hit this panic every time with an fs_mark test within a couple of minutes. With this patch I no longer hit the panic and fs_mark goes to completion. Thanks, Signed-off-by: Josef Bacik <josef@redhat.com>
Diffstat (limited to 'fs/btrfs/extent-tree.c')
0 files changed, 0 insertions, 0 deletions