Re: [PATCH] Introduce SEEK_DATA/SEEK_HOLE support V8

[Jeff Liu <jeff.liu@oracle.com>]

On 02/21/2012 10:56 PM, Mark Tinguely wrote:

> On 02/17/12 07:16, Jeff Liu wrote:
>> Hello,
>>
>> This is the revised patch according to Dave's comments for V7.
>>
>> Changes to V8:
>> --------------
>> 1. If there is an internal error raised at extent reading routine, just
>> return it rather than ENXIO.
>> 2. Add the commit message.
>> 3. Remove the for(;;) loop since there is no continuous holes shown even
>> if create a Petabyte sparse file with hole extent length longer than
>> 32-bit.  Thanks Dave for helping verify that!
>> 4. In xfs_seek_data(), s/len/end/, looks 'end' is more meaningful here
>> to indicate the range of extents mapped.
>> 5. Remove BUG() from xfs_seek_data() since xfs_bmapi_read() have found
>> any corruption during the lookup, it should not occurred at all.
>>
>> Any comments are appreciated!
>>
>> Thanks,
>> -Jeff
>>
>>
>> Signed-off-by: Jie Liu<jeff.liu@oracle.com>
> 
> ...
> 
>> +STATIC loff_t
>> +xfs_seek_hole(
> ...
>> +
>> +    fsbno = XFS_B_TO_FSBT(mp, start);
>> +    error = xfs_bmap_first_unused(NULL, ip, 1,&fsbno, XFS_DATA_FORK);
>> +    if (error)
>> +        goto out_unlock;
>> +
>> +    holeoff = XFS_FSB_TO_B(mp, fsbno);
>> +    if (holeoff<= start)
>> +        offset = start;
>> +    else
>> +        offset = min_t(loff_t, holeoff, isize);
>> +
> 
> ...
> 
> Very Nice. Much more concise.
> 
> Can xfs_bmap_first_unused() return something larger than the end of file?

I think it could be happen if the file has no holes past the given
offset. In this case, it will return the first block past the end of
file. That is why "min_t()" is used to determine the final value.

Thanks,
-Jeff

> 
> Reviewed-by: Mark Tinguely <tinguely@sgi.com>


_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs