| Message ID | 1372952919-21010-1-git-send-email-fdmanana@gmail.com (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Headers | show |
On Thu, Jul 4, 2013 at 4:48 PM, Filipe David Borba Manana <fdmanana@gmail.com> wrote: > If we did a tree search with the goal to find a metadata item > but the search failed with return value 1, we attempt to see > if in the same leaf there's a corresponding extent item, and if > there's one, just use it instead of doing another tree search > for this extent item. The check in the leaf was wrong because > it was seeking for a metadata item instead of an extent item. > > This optimization was also being triggered incorrectly, as it > was evaluating path->slots which always evaluates to true. The > goal was to see if the leaf level slot was greater than zero > (i.e. not the first item in the leaf). > > Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com> > --- > extent-tree.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/extent-tree.c b/extent-tree.c > index b0cfe0a..22e6247 100644 > --- a/extent-tree.c > +++ b/extent-tree.c > @@ -1515,12 +1515,13 @@ again: > * to make sure. > */ > if (ret > 0 && metadata) { > - if (path->slots) { > + if (path->slots[0]) { > path->slots[0]--; > btrfs_item_key_to_cpu(path->nodes[0], &key, > path->slots[0]); > if (key.objectid == bytenr && > - key.type == BTRFS_METADATA_ITEM_KEY) > + key.type == BTRFS_EXTENT_ITEM_KEY && > + key.offset == root->leafsize) > ret = 0; > } > > -- > 1.7.9.5 > Josef, since git suggests you are the author of this code piece, can you please review this and comment? Thanks. -- Filipe David Manana, "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men." -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/extent-tree.c b/extent-tree.c index b0cfe0a..22e6247 100644 --- a/extent-tree.c +++ b/extent-tree.c @@ -1515,12 +1515,13 @@ again: * to make sure. */ if (ret > 0 && metadata) { - if (path->slots) { + if (path->slots[0]) { path->slots[0]--; btrfs_item_key_to_cpu(path->nodes[0], &key, path->slots[0]); if (key.objectid == bytenr && - key.type == BTRFS_METADATA_ITEM_KEY) + key.type == BTRFS_EXTENT_ITEM_KEY && + key.offset == root->leafsize) ret = 0; }
If we did a tree search with the goal to find a metadata item but the search failed with return value 1, we attempt to see if in the same leaf there's a corresponding extent item, and if there's one, just use it instead of doing another tree search for this extent item. The check in the leaf was wrong because it was seeking for a metadata item instead of an extent item. This optimization was also being triggered incorrectly, as it was evaluating path->slots which always evaluates to true. The goal was to see if the leaf level slot was greater than zero (i.e. not the first item in the leaf). Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com> --- extent-tree.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)