xfs
[Top] [All Lists]

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

To: Eric Sandeen <sandeen@xxxxxxxxxxx>
Subject: Re: [PATCH] xfs_io: add the lseek() SEEK_DATA/SEEK_HOLE support
From: Mark Tinguely <tinguely@xxxxxxx>
Date: Wed, 21 Aug 2013 14:58:48 -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 (X11; FreeBSD amd64; rv:9.0) Gecko/20120122 Thunderbird/9.0
On 08/21/13 14:37, 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.

If the implementation can't really detect a hole, then everything is data.


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.

probably my bad notation - the data started at 12K ended at 16K-1. Some report the hole at the end of the file in bytes (16k), some cases as -1. Real fun stuff.

The current seek_data/seek_hole xfstest correct for this in the C code by say what values it will accept as being good.


It's not POSIX yet, so I guess there's no gospel, but that's what the man page 
says.

-Eric

--Mark.

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