From: Eric Sandeen <sandeen@sandeen.net>
To: Mark Tinguely <tinguely@sgi.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH] xfs_io: add the lseek() SEEK_DATA/SEEK_HOLE support
Date: Wed, 21 Aug 2013 14:37:51 -0500 [thread overview]
Message-ID: <5215170F.3050703@sandeen.net> (raw)
In-Reply-To: <521512E3.7090301@sgi.com>
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
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-08-21 19:37 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-16 20:54 [PATCH] xfs_io: add the lseek() SEEK_DATA/SEEK_HOLE support Mark Tinguely
2013-08-20 21:26 ` Rich Johnston
2013-08-20 23:07 ` Eric Sandeen
2013-08-21 14:14 ` Mark Tinguely
2013-08-21 16:28 ` Eric Sandeen
2013-08-21 16:52 ` Mark Tinguely
2013-08-21 18:31 ` Eric Sandeen
2013-08-21 19:20 ` Mark Tinguely
2013-08-21 19:37 ` Eric Sandeen [this message]
2013-08-21 19:55 ` Eric Sandeen
2013-08-21 19:58 ` Mark Tinguely
[not found] <20121022213759.033667921@sgi.com>
2012-10-22 21:38 ` Mark Tinguely
2012-10-22 23:29 ` Dave Chinner
2012-10-23 14:08 ` Mark Tinguely
2012-10-23 12:22 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5215170F.3050703@sandeen.net \
--to=sandeen@sandeen.net \
--cc=tinguely@sgi.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox