All of lore.kernel.org
 help / color / mirror / Atom feed
* A WARN_ON running fsstress punch hole
@ 2014-02-14  9:57 EthanLien
  0 siblings, 0 replies; only message in thread
From: EthanLien @ 2014-02-14  9:57 UTC (permalink / raw)
  To: linux-btrfs

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


^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2014-02-14 10:06 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-02-14  9:57 A WARN_ON running fsstress punch hole EthanLien

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.