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

[Reinoud Zandijk <reinoud%NetBSD.org@localhost>]

Hi David, hi folks,

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?

One `seeks' the next hole of data block in the file from a given pos? Sounds
logical to me.

The seek positions are returned by the lseek() calls. So yes, it changes the
file pointer too but thats a side-effect and the file pointer is not meant to
be used by multiple threads anyway. Just use pread()/pwrite() with mutexes. A
copier can thus only be:

    while (pos < extent) {
        data = lseek(fdi, pos, SEEK_DATA);
        hole = lseek(fdi, data, SEEK_HOLE);
        printf("DATA = %"PRIi64"\n", data);
        printf("HOLE = %"PRIi64"\n", hole);
        ....

And yes, it could be changed during the two calls but thats a race condition
anyway. I don't think whatever interface one uses that you can access a single
file without careful design.

Since its also used by Solaris and Linux (work-in-progress) more tools are
expected to at least look or it and basicly NetBSD doesn't have a tool to
manipulate or copy sparse files other than with 'dd conv=spare' or scanning it
trough with FIOBMAP for each file block which is not really that well defined
either, let alone portable.

With regards,
Reinoud