From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH 0/2] btrfs: trace: Add trace events for extent_io_tree
Date: Thu, 28 Feb 2019 18:02:53 +0800 [thread overview]
Message-ID: <20190228100255.10953-1-wqu@suse.com> (raw)
This patchset can be fetched from github:
https://github.com/adam900710/linux/tree/ftrace_extent_io_tree
Which is based on v5.0-rc7 tag.
Btrfs uses (almost abuse) extent_io_tree for a lot of operations, e.g:
- Tree block locking
BTRFS_I(btree_inode)->io_tree
- Page status tracing
BTRFS_I(file_inode)->io_tree and BTRFS_I(file_inode)->io_failure_tree
transaction->dirty_pages
- Pinned down extents tracing
fs_info->freed_extents[2]
...
However we don't have any trace events for us to understand how btrfs
works.
This patchset will introduce trace events for
set/clear/convert_extent_bit().
The output examples and extra notes are: (copied from the 2nd patch)
btrfs_set_extent_bit: io_tree=INODE_IO_TREE ino=1 root=1 start=22036480 len=4096 set_bits=LOCKED
btrfs_set_extent_bit: io_tree=INODE_IO_TREE ino=1 root=1 start=22040576 len=4096 set_bits=LOCKED
btrfs_set_extent_bit: io_tree=INODE_IO_TREE ino=1 root=1 start=22044672 len=4096 set_bits=LOCKED
btrfs_set_extent_bit: io_tree=INODE_IO_TREE ino=1 root=1 start=22048768 len=4096 set_bits=LOCKED
btrfs_clear_extent_bit: io_tree=INODE_IO_TREE ino=1 root=1 start=22036480 len=16384 clear_bits=LOCKED
^^^ Extent buffer 22036480 read from disc, the locking progress
btrfs_set_extent_bit: io_tree=TRANS_DIRTY_PAGES ino=1 root=1 start=30425088 len=16384 set_bits=DIRTY
btrfs_set_extent_bit: io_tree=TRANS_DIRTY_PAGES ino=1 root=1 start=30441472 len=16384 set_bits=DIRTY
^^^ 2 new tree blocks allocated in one transaction
btrfs_set_extent_bit: io_tree=FREED_EXTENTS0 ino=0 root=0 start=30523392 len=16384 set_bits=DIRTY
btrfs_set_extent_bit: io_tree=FREED_EXTENTS0 ino=0 root=0 start=30556160 len=16384 set_bits=DIRTY
^^^ 2 old tree blocks get pinned down
There are 2 points which need extra attention:
1) Those trace events are pretty heavy
The following workload would generate over 400 trace events.
mkfs.btrfs -f $dev
start_trace
mount $dev $mnt -o enospc_debug
sync
touch $mnt/file1
touch $mnt/file2
touch $mnt/file3
xfs_io -f -c "pwrite 0 16k" $mnt/file4
umount $mnt
end_trace
It's not recommended to use them in real world environment.
2) No way to distinguish between different btrfs filesystems
Due to the fact that we can't get fs_info easily from extent_io_tree,
there is no way to distinguish events from different fses.
To avoid extra noise, please ensure there is only one btrfs in your
test environment.
Qu Wenruo (2):
btrfs: Introduce extent_io_tree::owner to distinguish different
io_trees
btrfs: trace: Add trace events for extent_io_tree
fs/btrfs/disk-io.c | 12 ++-
fs/btrfs/extent_io.c | 7 +-
fs/btrfs/extent_io.h | 20 +++-
fs/btrfs/inode.c | 5 +-
fs/btrfs/relocation.c | 3 +-
fs/btrfs/tests/btrfs-tests.c | 6 +-
fs/btrfs/tests/extent-io-tests.c | 2 +-
fs/btrfs/transaction.c | 2 +-
include/trace/events/btrfs.h | 151 +++++++++++++++++++++++++++++++
9 files changed, 194 insertions(+), 14 deletions(-)
--
2.21.0
next reply other threads:[~2019-02-28 10:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-28 10:02 Qu Wenruo [this message]
2019-02-28 10:02 ` [PATCH 1/2] btrfs: Introduce extent_io_tree::owner to distinguish different io_trees Qu Wenruo
2019-02-28 15:32 ` David Sterba
2019-02-28 10:02 ` [PATCH 2/2] btrfs: trace: Add trace events for extent_io_tree Qu Wenruo
2019-02-28 15:24 ` David Sterba
2019-02-28 13:51 ` [PATCH 0/2] " David Sterba
2019-02-28 13:56 ` Qu Wenruo
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=20190228100255.10953-1-wqu@suse.com \
--to=wqu@suse.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox