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

[Eric Sandeen <sandeen@xxxxxxxxxxx>]

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.

-Eric