RFC: SEEK_HOLE/SEEK_DATA common implementation

Konstantin Belousov kostikbel at gmail.com
Thu Mar 29 09:34:37 UTC 2012


On Thu, Mar 29, 2012 at 12:14:15PM +0300, Gleb Kurtsou wrote:
> On (27/03/2012 21:34), Konstantin Belousov wrote:
> > Hello,
> > Please find at
> > http://people.freebsd.org/~kib/misc/seek_hole.1.patch
> > a prototype generic implementation of the SEEK_HOLE/SEEK_DATA lseek(2)
> > whence command for any filesystem that properly supports bmap.
> > 
> > I was unable to find any test suite for the feature, and the only more
> > or less reasonable case I found was from lklm, extracted at
> > http://people.freebsd.org/~kib/misc/seek_hole.c
> > The block for file with hole at the end is commented out because
> > UFS never puts holes at EOF. The block_size is tuned for default block
> > size on UFS on recent FreeBSD.
> > 
> > Filesystem-specific implementations could greatly increase the performance
> > of the call, because the presented implementation does linear search
> > through the blocks until hole/data boundary is found. E.g., for UFS,
> > the fast tree-like structure of indirect blocks can be traversed to
> > point at the next boundary. But this implementation is generic.
> 
> What do you think about replacing FIOSEEKHOLE/FIOSEEKDATA ioctls with
> VOP_SEEKHOLE (or similar). That would be more straightforward. Currently
> there is no way for a file system to use standard SEEKHOLE
> implementation without invoking vop_stdioctl. It handles only
> FIOSEEKHOLE now but that is likely to change in future. I wish we had no
> default VOP_IOCTL implementation and keep it file system specific.
This should be driven by ZFS guys.  If current structure makes the imports
from Illumos easier, then I prefer to not introduce new VOP. Otherwise,
feel free to change.

Filesystem probably should always fall back to calling vop_stdioctl()
manually if it ever implements VOP_IOCTL, regardless of seek_hole/data.

> 
> We should also return valid _PC_MIN_HOLE_SIZE (=mnt_stat.f_iosize) in
> VOP_PATHCONF for userland to see SEEK_HOLE/SEEK_DATA support.
Yes, but there is more inconsitencies between manpage and ZFS implementation,
at least it seems so from my reading.  Currently I am more interested in
the comments about the approach itself.

> 
> I'm not sure enabling it by default is desirable, performance penalty
> can be considerable. Consider creating tar archive of large files with
> O(file size) SEEK_HOLE enabled. On the other hand default implementation
> can be useful, e.g. if file system had internal flag for sparse files it
> could simply reuse default vop_stdseekhole() avoiding overhead for
> non-sparse files.
I do not understand this. Can you provide some numbers illustrating
your concerns ?

And yes, I would be happy to get some testing results from applications
that already use the interface, but this is a blue dream. There are too
many corner cases in the interface that seems to be not documented and
I was unable to find test giving good coverage.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20120329/6daaf4dc/attachment.pgp


More information about the freebsd-fs mailing list