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

[jnemeth%victoria.tc.ca@localhost (John Nemeth)]

On Dec 28,  1:27pm, Reinoud Zandijk wrote:
} 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.

     Sounds like rationalising to me.  David is right, this is a truely
brain dead interface.  Having said that, I understand that sometimes we
get stuck with brain dead interfaces simply because they get into
common use.  The question is, do we have time to come with a better
interface that we can hopefully encourage others to use?  Or, is this
one already in common use across multiple OSes and applications?

}-- End of excerpt from Reinoud Zandijk