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

Eric Sandeen
2013-08-21T19:37:56Z

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