Subject: Re: lseek() extension for spare files
To: Bill Studenmund <wrstuden@netbsd.org>
From: Reinoud Zandijk <reinoud@netbsd.org>
List: tech-kern
Date: 09/21/2006 22:20:51
--CE+1k2dSO48ffgeK
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Dear Bill,
On Thu, Sep 21, 2006 at 11:19:14AM -0700, Bill Studenmund wrote:
> > It adds the SEEK_DATA and SEEK_HOLE `whence' arguments to lseek(). For a
> > more detailed look see the solaris 10 man page :
> >
> > http://tinyurl.com/fk6we
> >
> > Although its pretty complete and smoothed out it might need some fine
> > tuning. Note that in this patch no file system has yet implemented sparse
> > area reporting and the genfs implementation, that allmost all use,
> > implements the basic functionality.
>
> How will we implement the guts of SEEK_DATA and SEEK_HOLE? If we've handed
> the whole VOP off to genfs, we don't have an fs-specific callback.
>
> I think what we should do is have each fs have its own seek routine, which
> calls a genfs routine with the vop info plus a callback to handle finding
> regions. Either that, or to the extent we have genfs-ops, we need another
> one.
As discussed earlier i've moved the implementation of the `whence' to the
file system vnode. To ease the implementation i've passed the relevant data
down stream and all file systems that don't support sparse files natively
like msdosfs just use the genfs_seek function. It will provide a
minimalistic but correct behaviour for normal seeks and for data/hole
searches.
Each file system that does want to provide sparcity information can either
implement it as a seek for zero's (not really encouraged but never the less
possible) or seek its datastructures and give the offsets asked for. One
call can only return one offset so no lists have to be made.
Note that the interface definition in the Solaris manpage does not state
that data area's don't have zero regions nor that holes have a minimal
size.
I think generally speaking for most file systems holes are defined in terms
of sector size blocks anyway and can be searched for in its own way.
If i understand FFS enough, it could be that the file's allocation tree can
be searched and the relevant region extracted at allmost no cost; esp. if
you count the reading and movement of all that dummy data to userland.
In UDF f.e. each file is defined as a series of extents on blocksize
lengths (either not allowed or allocated but not used) and so for UDF its
just searching the extent list for what's next to the extent referenced and
return that offset.
With regards,
Reinoud
--CE+1k2dSO48ffgeK
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (NetBSD)
iQEVAwUBRRL0HIKcNwBDyKpoAQIQwgf+Ozz1zfXYa6WAItfdyNotDQ2kvoIcdRhl
XPsHx8VAjC+n1y3nVkWqH3S6BqsHq5zhWswa05qYLEfGBnKLAoOB/cq2wdtlreTS
mI6U47a6R9/WqlpfTbgccTHILwUGD7B86IH75ICvluCZlQQzdztksSaRkTCBMwdB
G/L6KN9ojvKSzdQcVzAMlFj4koGzbslqQZ3ulbTglpLytrHBIBr43ZvqPlyxgYo/
wtHpc17K8bvS795CQ7y9Sv6YAAhx8lEWD8mqHWVcF64ACx5nRGunBjhjaIQHiKA4
zv0dh4/2kyTC1FmyZnOEezR6tbdk3MzKZktCeqY5nNfgWeI1jZ92WQ==
=K7aP
-----END PGP SIGNATURE-----
--CE+1k2dSO48ffgeK--