From: EthanLien <ethanlien@synology.com>
To: linux-btrfs@vger.kernel.org
Subject: A WARN_ON running fsstress punch hole
Date: Fri, 14 Feb 2014 17:57:36 +0800 [thread overview]
Message-ID: <52FDE890.8060208@synology.com> (raw)
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
reply other threads:[~2014-02-14 10:06 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52FDE890.8060208@synology.com \
--to=ethanlien@synology.com \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.