Re: RFC: SEEK_DATA/SEEK_HOLE implementation version 2

[Alan Barrett <apb%cequrux.com@localhost>]

On Wed, 17 Aug 2011, Reinoud Zandijk wrote:
> after getting stuck in the 1st implementation in the 
> rump/puffs/refuse jungle i started a new version that is more in 
> line with the Solaris implementation and is far less invasive.
>
> Basicly the system call forwards the requests using ioctl's just 
> like Solaris and, as it turns out, also FreeBSD with their ZFS 
> import. For simplicity and to reduce compat stuff i've used the 
> same ioctls FreeBSD defines. FreeBSDs support is limited though; 
> only ZFS handles them. The ioctl names are not documented yet.

So, if I am reverse engineering the code correctly, the design is 
like this:

  There are no new VOP calls.

  There are two new ioctls, FIOSEEKDATA and FIOSEEKHOLE.  Each
  file system may provide its own implementation.  If the
  underlying file system doesn't support them, then they fail.

  There are two new lseek 'whence' flags, SEEK_DATA and SEEK_HOLE.
  The kernel's lseek implementation forwards them to the
  underlying file system using VOP_IOCTL(FIOSEEKDATA) and
  VOP_IOCTL(FIOSEEKHOLE).  If the ioctl fails, then lseek
  implements the fallback behaviour of treating the file as a
  single data region followed by a hole after the end of file.

I think that it would be better to implement the fallback behaviour in
the vfs layer rather than in the lseek syscall.

--apb (Alan Barrett)