linux-btrfs.vger.kernel.org archive mirror
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).