xfs
[Top] [All Lists]

Re: [PATCH] xfs_io: add the lseek() SEEK_DATA/SEEK_HOLE support

To: Mark Tinguely <tinguely@xxxxxxx>
Subject: Re: [PATCH] xfs_io: add the lseek() SEEK_DATA/SEEK_HOLE support
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Wed, 21 Aug 2013 14:55:43 -0500
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <5215170F.3050703@xxxxxxxxxxx>
References: <20130816205409.976658624@xxxxxxx> <5213F6AF.8070107@xxxxxxxxxxx> <5214CB5C.4050608@xxxxxxx> <5214EAAC.80800@xxxxxxxxxxx> <5214F050.7060402@xxxxxxx> <52150775.1050705@xxxxxxxxxxx> <521512E3.7090301@xxxxxxx> <5215170F.3050703@xxxxxxxxxxx>
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
On 8/21/13 2:37 PM, Eric Sandeen wrote:
> On 8/21/13 2:20 PM, Mark Tinguely wrote:
>> On 08/21/13 13:31, Eric Sandeen wrote:
> 
> ...
> 
>>>> There are different versions of XFS seek_data and they will
>>>> detect/report the start of data and holes differently so output
>>>> parsing will be a bear. The existing C code sends the 2 different
>>>> value numbers that could be reported.
>>>
>>> are they ... both correct?  If one is a bug, it can just be a bug, right?
>>> I'm sorry I'm not up on the history.
>>
>> Lets say we have a file
>> hole    0-4K
>> data    4K-8K
>> hole    8-12K
>> data    12-16K
>>
>> for data/hole check starting at offset 0, valid response are
>> 0K or 4K for data
>> 0K or 16K or -1 for holes
>>
>> This feature and test was for Jeff fine-tuned seek_data/seek_hole support. 
>> The tests would be more specific to that feature and output is specific.
> 
> Well, at least the man page says:
> 
>> SEEK_DATA
>> Adjust the file offset to the next location in the file greater than
>> or equal to offset containing data. If offset points to data, then
>> the file offset is set to offset.
> 
> So above, if we say "SEEK_DATA at offset 0" it seems like 0k is clearly 
> wrong, and 4k is clearly right.
>  
>> SEEK_HOLE
>> Adjust the file offset to the next hole in the file greater than or
>> equal to offset. If offset points into the middle of a hole, then the
>> file offset is set to offset. If there is no hole past offset, then
>> the file offset is adjusted to the end of the file (i.e., there is an
>> implicit hole at the end of any file).
> 
> and "SEEK_HOLE at offset 0" should pretty clearly return 0, and 16k would be 
> wrong.
> 
> It's not POSIX yet, so I guess there's no gospel, but that's what the man 
> page says.

though I see the seek sanity test has all kinds of exceptions.  Yuck.

So back to: Just report what lseek says, and leave interpretation to the 
caller. ;)

-Eric

> -Eric
> 
> _______________________________________________
> xfs mailing list
> xfs@xxxxxxxxxxx
> http://oss.sgi.com/mailman/listinfo/xfs
> 

<Prev in Thread] Current Thread [Next in Thread>