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

[David Laight <david%l8s.co.uk@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?

If you are looking for holes (probably to avoid copying them), then
the code probably wants exclusive access to the file anyway - otherwise
any info about holes is likely to be stale.

Thinks further... maybe you should be able to find a hole from a
specified point in the file, not just the current offset.

So:
    lseek(fd, offset, SEEK_SET | SEEK_HOLE)
would find the first hole beyond offset.
The function from solaris is probably:
    lseek(fd, 0, SEEK_CUR | SEEK_HOLE)

Actually a bigger problem for multiple threads accessing the same
file is that none of the file locking schemes work.

        David

-- 
David Laight: david%l8s.co.uk@localhost