From: Josef Bacik <jbacik@fusionio.com>
To: Alex Lyakas <alex.bolshoy.btrfs@gmail.com>
Cc: Josef Bacik <JBacik@fusionio.com>,
"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH] Btrfs: try to avoid doing a search in btrfs_next_leaf
Date: Mon, 1 Oct 2012 12:45:14 -0400 [thread overview]
Message-ID: <20121001164514.GA2370@localhost.localdomain> (raw)
In-Reply-To: <CAHf9xvbZTizo6nbDbX8vjbT2RrwzPm=JMm-ms2MB-SVVcDKRhQ@mail.gmail.com>
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
next prev parent reply other threads:[~2012-10-01 16:45 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-24 20:02 [PATCH] Btrfs: try to avoid doing a search in btrfs_next_leaf Josef Bacik
2012-09-30 11:28 ` Alex Lyakas
2012-10-01 16:45 ` Josef Bacik [this message]
2012-10-02 8:17 ` Alex Lyakas
2012-10-02 14:25 ` David Sterba
2012-10-02 14:32 ` Josef Bacik
2012-10-02 15:05 ` David Sterba
2012-10-02 15:27 ` Josef Bacik
2012-10-02 15:30 ` Arne Jansen
2012-10-03 12:57 ` Alex Lyakas
2012-10-03 13:32 ` Josef Bacik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121001164514.GA2370@localhost.localdomain \
--to=jbacik@fusionio.com \
--cc=alex.bolshoy.btrfs@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).