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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html