On Tue, Apr 10, 2018 at 10:45:39AM +0300, Nikolay Borisov wrote:
> On  9.04.2018 14:58, David Sterba wrote:
> > We really want to know to which filesystem the extent map events belong,
> > but as it cannot be reached from the extent_map pointers, we need to
> > pass it down the callchain.
> I really dislike propagating arguments solely for tracepoints purposes,
> but if we don't have any other choice then I guess we should go with it.
> However...
> > @@ -7092,7 +7092,7 @@ struct extent_map *btrfs_get_extent(struct 
> > btrfs_inode *inode,
> >  
> >     err = 0;
> >     write_lock(&em_tree->lock);
> > -   err = btrfs_add_extent_mapping(em_tree, &em, start, len);
> > +   err = btrfs_add_extent_mapping(fs_info, em_tree, &em, start, len);
> This function is called only here, and we know that em_tree passed
> points to a struct, stored in btrfs_inode. So can't we use container_of
> to get the btrfs_inode in this function, from where we can reference the
> fs_info? I guess it could be a problem for tests.
> Admittedly  this feels somewhat hacky and I guess is not very
> future-proof, but it's still a viable alternative.

Sounds too fragile to me, from all the alternatives passing fs_info
looks like the cleanest way for now.  The filesystem UUID in the
tracepoint is IMO an important part.
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to