From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH v2 0/3] btrfs: trace: Add trace events for extent_io_tree
Date: Fri, 1 Mar 2019 10:47:57 +0800 [thread overview]
Message-ID: <20190301024800.17649-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().
Despite that, there are some other small modifications required:
- Introduce extent_io_tree::fs_info
For trace events to output fsid to distinguish different fs.
This increase the size of extent_io_tree by 8 bytes.
- Allow NULL fs_info for TP_fast_assign_fsid()
There is extent bits operation in selftest which is too deep to pass
fs_info. And since it's in selftest, it shouldn't trigger trace
events.
But to be safe, we still need to check fs_indo in
TP_fast_assign_fsid(), for NULL fs_info, just keep fsid filled with
zero.
- New extent_io_tree::owner
To distinguish different extent io trees. It uses the unpopulated bits
of original trace_uptodate, so it doesn't increase the size of
extent_io_tree.
The output examples and extra notes are: (copied from the 3rd patch)
btrfs_set_extent_bit: <FDID>: io_tree=IO_TREE ino=1 root=1 start=22036480 len=4096 set_bits=LOCKED
btrfs_set_extent_bit: <FSID>: io_tree=IO_TREE ino=1 root=1 start=22040576 len=4096 set_bits=LOCKED
btrfs_set_extent_bit: <FSID>: io_tree=IO_TREE ino=1 root=1 start=22044672 len=4096 set_bits=LOCKED
btrfs_set_extent_bit: <FSID>: io_tree=IO_TREE ino=1 root=1 start=22048768 len=4096 set_bits=LOCKED
btrfs_clear_extent_bit: <FSID>: io_tree=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: <FSID>: io_tree=TRANS_DIRTY_PAGES ino=1 root=1 start=30425088 len=16384 set_bits=DIRTY
btrfs_set_extent_bit: <FSID>: 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: <FSID>: io_tree=FREED_EXTENTS0 ino=0 root=0 start=30523392 len=16384 set_bits=DIRTY
btrfs_set_extent_bit: <FSID>: io_tree=FREED_EXTENTS0 ino=0 root=0 start=30556160 len=16384 set_bits=DIRTY
^^^ 2 old tree blocks get pinned down
There is one point 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.
Changelog:
v2:
- Introduce fs_info to distinguish different btrfs filesystems
- Code style change to make trace code more elegant
- Minor IO_TREE_* naming change.
- Use btrfs_ino() to replace raw inode number.
- Change extent_io_tree::owner declaration to avoid affecting spinlock.
Qu Wenruo (3):
btrfs: Introduce fs_info for extent_io_tree
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 | 9 +-
fs/btrfs/extent_io.h | 22 ++++-
fs/btrfs/inode.c | 6 +-
fs/btrfs/relocation.c | 9 +-
fs/btrfs/tests/btrfs-tests.c | 6 +-
fs/btrfs/tests/extent-io-tests.c | 2 +-
fs/btrfs/transaction.c | 4 +-
include/trace/events/btrfs.h | 159 ++++++++++++++++++++++++++++++-
9 files changed, 210 insertions(+), 19 deletions(-)
--
2.21.0
next reply other threads:[~2019-03-01 2:48 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-01 2:47 Qu Wenruo [this message]
2019-03-01 2:47 ` [PATCH v2 1/3] btrfs: Introduce fs_info for extent_io_tree Qu Wenruo
2019-03-01 2:47 ` [PATCH v2 2/3] btrfs: Introduce extent_io_tree::owner to distinguish different io_trees Qu Wenruo
2019-03-07 17:10 ` David Sterba
2019-03-11 15:20 ` David Sterba
2019-03-01 2:48 ` [PATCH v2 3/3] btrfs: trace: Add trace events for extent_io_tree Qu Wenruo
2019-03-07 17:14 ` David Sterba
2019-03-07 16:32 ` [PATCH v2 0/3] " David Sterba
2019-03-08 0:41 ` Qu Wenruo
-- strict thread matches above, loose matches on Subject: below --
2019-03-01 2:45 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=20190301024800.17649-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 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.