Re: RFC: SEEK_DATA/SEEK_HOLE implementation version 2

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

On Mon, Oct 03, 2011 at 08:33:06AM +0200, Alan Barrett wrote:
> So, if I am reverse engineering the code correctly, the design is 
> like this:
> 
>   There are no new VOP calls.
correct

>   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.

correct

>   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.

The vfs lseek system call does that yes

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

I tried that before and it was in my origional patch. I changed the VOP_SEEK()
to accept the other two `whence' argument values. This however meant that
VOP_SEEK()'s prototype had to be extended resulting in severe compatibility
issues with puffs/rump/(re)fuse etc. resulting in a HUGE patchset.  Also,
external maintained code like ZFS had to be changed.

Apart from this, David Holland was not content with this approach either since
it would mean that its information would ONLY be retrieveable by lseek()
changing the file pointer on the way. By exposing the ioctl() to userland,
multithreadded applications can also independently walk the info without
changing the file pointer on the way improving compatability side effects.

For the second patch, i choose to follow the Solaris/FreeBSD way to use the
ioctl()s since they would need to be included for compat anyway. This also
means that with some minor undefines, ZFS will have the ioctl code
implementation already too.

Does this answer your question?

With regards,
Reinoud