Hello,
I used the command "fsstress -f punch=20 -d /volume1 -n 10000 -p 50"
to repeatedly stress my btrfs volume
After a few hours stress, I got a WARN_ON at fs/btrfs/file.c:553
It seems someone gave btrfs_drop_extent_cache a range to drop
where end < start
The call flow is btrfs_punch_hole , __btrfs_drop_extents , fill_holes ,
btrfs_drop_extent_cache. I found when the WARN_ON was hit,
__btrfs_drop_extents sent a range where cur_offset == drop_end
thus caused the WARN_ON
Now I think there may be some problems with __btrfs_drop_extents.
I set some logs in __btrfs_drop_extents and find it will return
*drop_end = start and the return value ret is still 0 in some situations.
In this situation, __btrfs_drop_extents intends to drop many extents.
The first extent is truncated, and the extent_end is set to start. The
following extents are entirely dropped. Finally, it loops back to the
beginning
of the while loop and uses btrfs_next_leaf to search next leaf, but somehow
it gets the extent which is first truncated and thus return *drop_end =
start
Has anyone ever met problem like this?
Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
