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:37:51 -0500
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <521512E3.7090301@xxxxxxx>
References: <20130816205409.976658624@xxxxxxx> <5213F6AF.8070107@xxxxxxxxxxx> <5214CB5C.4050608@xxxxxxx> <5214EAAC.80800@xxxxxxxxxxx> <5214F050.7060402@xxxxxxx> <52150775.1050705@xxxxxxxxxxx> <521512E3.7090301@xxxxxxx>
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: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

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