Re: [PATCH RFCv2] new ioctl TREE_SEARCH_V2

[Gerhard Heift <gerhard@heift.name>]

2014-01-28 Anand Jain <Anand.Jain@oracle.com>:
>  You may have covered this but its not explicit.
>  Could you write few lines on whats wrong with the current
>  TREE SEARCH and how V2 is helping.

I wrote a program, which basically calculates a checksum over a files
content checksums. First I got the fiemap of the file and then
searched for the csum items with

  objectid: BTRFS_EXTENT_CSUM_OBJECTID;
  type: BTRFS_EXTENT_CSUM_KEY;
  offset: [physical pages]

This worked good but sometimes resulted in a empty items, because they
did not fit in the given buffer of 3992 bytes, specially for large
files. As David worte in [1], EXTENT_CSUM items seem to cap at 16k. A
simple solution would have been to just expand the static buffer size,
but with this solution, the user can decide how much buffer is needed.
Either way, directly copying the data to userspace with
read_extent_buffer_to_user (as suggested in [2]) will eliminate the
double-copy of data and needs less memory in the kernel.

[1] http://article.gmane.org/gmane.comp.file-systems.btrfs/31765
[2] http://article.gmane.org/gmane.comp.file-systems.btrfs/32064

> Thanks, Anand
>
>
>
>
> On 01/27/2014 09:28 PM, Gerhard Heift wrote:
>>
>> This patch series adds a new ioctl TREE_SEARCH_V2 with which we could
>> store the
>> results in a varying buffer. Now even items larger than 3992 bytes or a
>> large
>> amount of items can be returned.
>>
>> I have a few questions:
>>    Which value should I assign to TREE_SEARCH_V2?
>>    Should we limit the buffer size?
>>    What about documentation?
>>
>> Changelog
>>
>> RFCv2
>>    * fixed a build bug caused by using a wrong patch
>>    * added a patch to expand buffer lifetime
>>
>> Gerhard
>>
>> --
>> 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