On 2016-06-14 20:16, Hugo Mills wrote: [....] >> >> You are right. If the last item in the buffer is a EXTENT_ITEM, and the >> next item in the disk is a BLOCK_GROUP_ITEM with the same object id, >> the latter would be skipped. >> >> I was find always terrible the BTRFS_IOC_TREE_SEARCH; if the min_* >> fields was separate from the key, the use of this ioctl would >> be a lot simpler. Moreover in most case (like this one), it would be >> reduced the context switches, because the ioctl would return >> only valid data. > > There's an argument for implementing it. However, given the way the > indexing works (concatenation of the key elements, resulting in > lexical ordering of keys), you'd still have to do exactly the same > work, only in the kernel instead. The only thing you really win is the > number of context switches. > > It would really have to be a new ioctl, too. You can't change the > behaviour of the existing one. > > Hugo. It was 2010... http://www.spinics.net/lists/linux-btrfs/msg07636.html > >>> >>> 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..." >>> >> >> > -- gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- 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
