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
