Hi Josef, thanks for clarifying. By "wants to walk forward based on a particular item" you mean - find all items that have the same objectid, until objectid changes? I wrote some code once (for educational purposes) that just walked the tree irrespective of a particular objectid, so that's why I was somewhat puzzled by your change. If you decide to keep your change, can you pls update the comment of btrfs_next_leaf()/next_old_leaf(). Thanks again, Alex. On Mon, Oct 1, 2012 at 6:45 PM, Josef Bacik <jbacik@xxxxxxxxxxxx> wrote: > On Sun, Sep 30, 2012 at 05:28:23AM -0600, Alex Lyakas wrote: >> Hi Josef, >> I guess I am missing something, but I thought btrfs_next_leaf() should >> just jump to the next leaf (or item, if it was added meanwhile) >> irrespective of the key that is in the last slot of the current leaf. >> The change you added is effective when there is a next leaf, but you >> refuse to go there unless its first key has the same objectid. (I >> think you use the ctree property that the key in the first node/leaf >> of a tree block is equal to its parent's key). >> Can you pls explain why you insist on the same objectid? >> > > It's to avoid another search forward. Unless I missed something everybody who > calls btrfs_next_leaf() only wants to walk forward based on a particular item. > If I've missed something and that's not the case then this needs to be dropped, > or we can set some flag in path to ignore this logic, either way. Thanks, > > Josef -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
