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