Hi!
On 06/12/2016 08:41 PM, Goffredo Baroncelli wrote:
Hi All,
On 2016-06-10 22:47, Hans van Kranenburg wrote:
+ if (sk->min_objectid < sk->max_objectid) +
sk->min_objectid += 1;
...and now it's (289406977 168 19193856), which means you're
continuing your search *after* the block group item!
(289406976 168 19193856) is actually (289406976 << 72) + (168 <<
64) + 19193856, which is 1366685806470112827871857008640
The search is continued at 1366685811192479310741502222336, which
skips 4722366482869645213696 possible places where an object could
live in the tree.
I am not sure to follow you. The extent tree (the tree involved in
the search), contains only two kind of object:
- BLOCK_GROUP_ITEM where the key means (logical address, 0xc0, size
in bytes)
- EXTENT_ITEM, where the key means (logical address, 0xa8,
size in bytes)
So it seems that for each (possible) "logical address", only two
items might exist; the two item are completely identified by
(objectid, type, ). It should not possible (for the extent tree) to
have two item with the same objectid,key and different offset. So,
for the extent tree, it is safe to advance only the objectid field.
I am wrong ?
When calling the search ioctl, the caller has to provide a memory buffer
that the kernel is going to fill with results. For BTRFS_IOC_TREE_SEARCH
used here, this buffer has a fixed size of 4096 bytes. Without some
headers etc, this leaves a bit less than 4000 bytes of space for the
kernel to write search result objects to.
If I do a search that will result in far more objects to be returned
than possible to fit in those <4096 bytes, the kernel will just put a
few in there until the next one does not fit any more.
It's the responsibility of the caller to change the start of the search
to point just after the last received object and do the search again, in
order to retrieve a few extra results.
So, the important line here was: "...when the extent_item just manages
to squeeze in as last result into the current result buffer from the
ioctl..."
--
Hans van Kranenburg - System / Network Engineer
T +31 (0)10 2760434 | hans.van.kranenburg@xxxxxxxxxx | www.mendix.com
--
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
