diff options
author | Josef Bacik <josef@redhat.com> | 2009-09-11 16:11:19 -0400 |
---|---|---|
committer | Chris Mason <chris.mason@oracle.com> | 2009-09-21 19:23:48 -0400 |
commit | ba1bf4818baf68d914ef9e3b06fbea6acb674fe4 (patch) | |
tree | 1068d6ce508333a75668181bfe0e42956d4d8780 /usr | |
parent | 1fb58a6051cd904a9f8e0344b22e31921d6b5a4d (diff) | |
download | linux-stable-ba1bf4818baf68d914ef9e3b06fbea6acb674fe4.tar.gz linux-stable-ba1bf4818baf68d914ef9e3b06fbea6acb674fe4.tar.bz2 linux-stable-ba1bf4818baf68d914ef9e3b06fbea6acb674fe4.zip |
Btrfs: make balance code choose more wisely when relocating
Currently, we can panic the box if the first block group we go to move is of a
type where there is no space left to move those extents. For example, if we
fill the disk up with data, and then we try to balance and we have no room to
move the data nor room to allocate new chunks, we will panic. Change this by
checking to see if we have room to move this chunk around, and if not, return
-ENOSPC and move on to the next chunk. This will make sure we remove block
groups that are moveable, like if we have alot of empty metadata block groups,
and then that way we make room to be able to balance our data chunks as well.
Tested this with an fs that would panic on btrfs-vol -b normally, but no longer
panics with this patch.
V1->V2:
-actually search for a free extent on the device to make sure we can allocate a
chunk if need be.
-fix btrfs_shrink_device to make sure we actually try to relocate all the
chunks, and then if we can't return -ENOSPC so if we are doing a btrfs-vol -r
we don't remove the device with data still on it.
-check to make sure the block group we are going to relocate isn't the last one
in that particular space
-fix a bug in btrfs_shrink_device where we would change the device's size and
not fix it if we fail to do our relocate
Signed-off-by: Josef Bacik <jbacik@redhat.com>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
Diffstat (limited to 'usr')
0 files changed, 0 insertions, 0 deletions