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
