Skip to contentSkip to conversation

Btrfs: fix oops while writing data to SSD partitions

PATCH In review liubo 2 participants 3 messages Jul 27, 2011 – Jul 28, 2011 Btrfs file system

lore
Share & tools
lore

liubo

author
#0 lore raw

PATCH 1/1 Btrfs: fix oops while writing data to SSD partitions

Here I have a two SSD-partitions btrfs, and they are defaultly set to "data=raid0, metadata=raid1", then I try to fill my btrfs partition till "No space left on device", via "dd if=/dev/zero of=/mnt/btrfs/tmp".

I get an oops panic from kernel BUG at fs/btrfs/extent-tree.c:5199!, which refers to find_free_extent's
BUG_ON(index != get_block_group_index(block_group));

In SSD mode, in order to find enough space to alloc, we may check the block_group cache which has been checked sometime before, but the index is not updated, where it hits the BUG_ON.

---
 fs/btrfs/extent-tree.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)
fs/btrfs/extent-tree.c +3 -1
index 71cd456..3213c39 100644
@@ -5065,7 +5065,9 @@ have_block_group:
 			 * group is does point to and try again
 			 */
 			if (!last_ptr_loop && last_ptr->block_group &&
-			    last_ptr->block_group != block_group) {
+			    last_ptr->block_group != block_group &&
+			    index <=
+				 get_block_group_index(last_ptr->block_group)) {
 
 				btrfs_put_block_group(block_group);
 				block_group = last_ptr->block_group;
Signature · 1 line
1.6.5.2
Acked-by on v1 1/1
#1 lore raw
Quoted 22 lines · liubo

Here I have a two SSD-partitions btrfs, and they are defaultly set to "data=raid0, metadata=raid1", then I try to fill my btrfs partition till "No space left on device", via "dd if=/dev/zero of=/mnt/btrfs/tmp".

I get an oops panic from kernel BUG at fs/btrfs/extent-tree.c:5199!, which refers to find_free_extent's
BUG_ON(index != get_block_group_index(block_group));

In SSD mode, in order to find enough space to alloc, we may check the block_group cache which has been checked sometime before, but the index is not updated, where it hits the BUG_ON.

---
 fs/btrfs/extent-tree.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)
fs/btrfs/extent-tree.c +0 -0
index 71cd456..3213c39 100644

fs/btrfs/extent-tree.c have_block_group: · line 5073

Quoted 10 lines
fs/btrfs/extent-tree.c +3 -1
@@ -5065,7 +5065,9 @@ have_block_group:
 			 * group is does point to and try again
 			 */
 			if (!last_ptr_loop && last_ptr->block_group &&
-			    last_ptr->block_group != block_group) {
+			    last_ptr->block_group != block_group &&
+			    index <=
+				 get_block_group_index(last_ptr->block_group)) {
 
 				btrfs_put_block_group(block_group);
 				block_group = last_ptr->block_group;

Ugh I wish we could make this prettier but

Thanks,

Josef

author
#2 lore raw
Quoted 31 lines · Josef Bacik
Quoted 30 lines · liubo

Here I have a two SSD-partitions btrfs, and they are defaultly set to "data=raid0, metadata=raid1", then I try to fill my btrfs partition till "No space left on device", via "dd if=/dev/zero of=/mnt/btrfs/tmp".

I get an oops panic from kernel BUG at fs/btrfs/extent-tree.c:5199!, which refers to find_free_extent's
BUG_ON(index != get_block_group_index(block_group));

In SSD mode, in order to find enough space to alloc, we may check the block_group cache which has been checked sometime before, but the index is not updated, where it hits the BUG_ON.

---
 fs/btrfs/extent-tree.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)
fs/btrfs/extent-tree.c +3 -1
index 71cd456..3213c39 100644
@@ -5065,7 +5065,9 @@ have_block_group:
 			 * group is does point to and try again
 			 */
 			if (!last_ptr_loop && last_ptr->block_group &&
-			    last_ptr->block_group != block_group) {
+			    last_ptr->block_group != block_group &&
+			    index <=
+				 get_block_group_index(last_ptr->block_group)) {
 
Quoted 7 lines

fs/btrfs/extent-tree.c have_block_group: · line 5073

Quoted 2 lines
fs/btrfs/extent-tree.c +0 -0
 				btrfs_put_block_group(block_group);
 				block_group = last_ptr->block_group;

Ugh I wish we could make this prettier but

I wish that, too. ;)

But lots of goto really make life harder...we can somehow improve it later.

thanks,
liubo

Quoted 4 lines

Thanks,

Josef