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