Re: [PATCH v2 14/19] btrfs: make btree inode io_tree has its special owner

David Sterba
2020-09-17T13:03:39Z

On Thu, Sep 17, 2020 at 08:02:05AM +0800, Qu Wenruo wrote:
>
>
> On 2020/9/17 上午12:06, David Sterba wrote:
> > On Tue, Sep 15, 2020 at 01:35:27PM +0800, Qu Wenruo wrote:
> >> Btree inode is pretty special compared to all other inode extent io
> >> tree, although it has a btrfs inode, it doesn't have the track_uptodate
> >> bit at all.
> >>
> >> This means a lot of things like extent locking doesn't even need to be
> >> applied to btree io tree.
> >>
> >> Since it's so special, adds a new owner value for it to make debuging a
> >> little easier.
> >>
> >> Signed-off-by: Qu Wenruo <wqu@suse.com>
> >> ---
> >> fs/btrfs/disk-io.c | 2 +-
> >> fs/btrfs/extent-io-tree.h | 1 +
> >> 2 files changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
> >> index 1ba16951ccaa..82a841bd0702 100644
> >> --- a/fs/btrfs/disk-io.c
> >> +++ b/fs/btrfs/disk-io.c
> >> @@ -2126,7 +2126,7 @@ static void btrfs_init_btree_inode(struct btrfs_fs_info *fs_info)
> >>
> >> RB_CLEAR_NODE(&BTRFS_I(inode)->rb_node);
> >> extent_io_tree_init(fs_info, &BTRFS_I(inode)->io_tree,
> >> - IO_TREE_INODE_IO, inode);
> >> + IO_TREE_BTREE_IO, inode);
> >
> > This looks like an independent patch, so it could be taken separately.
> >
> Errr, why?
>
> We added a new owner for btree inode io tree, and utilize that new owner
> in the same patch looks completely sane to me.
>
> Or did I miss something?

The IO_TREE_* ids are only for debugging and IO_TREE_INODE_IO is
supposed to be used for data inodes. But the btree_inode has that too,
which does not seem to follow the purpose of the tree id, you fix that
in this patch and it applies to current code too.