Re: RFC: lseek() extensions: SEEK_HOLE / SEEK_DATA with patch

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

On Sun, Aug 07, 2011 at 02:14:50PM +0000, David Holland wrote:
> On Sun, Aug 07, 2011 at 09:52:11AM +0200, Reinoud Zandijk wrote:
>  > i've implemented the SEEK_HOLE / SEEK_DATA additions to lseek() as
>  > introduced by Solaris for ZFS.
> 
> What does this operation have to do with seeking? And why involve the
> seek pointer, especially at a time when new calls are being added left
> and right to cope with files accessed from more than one thread at a
> time in the same process?

The use cases I know are interested in one of the following three
properties:

(1) The list of all holes.

(2) Where the next hole is relative to the current position in the file.

(3) If the file starts with a hole.

You can substitute hole for data for symmetry.

I don't know of any application that actually cares about concurrent
access to the same file object when processing holes. That is, the
processing of holes is done as part of a library and the file object is
under the exclusive control of that library. As such, I consider the
"modifies file position" argument weak and not enough justification to
divert from the existing API.

Given the property (2), an API independent of the file position is
suboptimal too. fcntl would have to reinvent the wheel in that case too.

Joerg