Date: Thu, 29 Mar 2012 12:34:27 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Gleb Kurtsou <gleb.kurtsou@gmail.com> Cc: fs@freebsd.org Subject: Re: RFC: SEEK_HOLE/SEEK_DATA common implementation Message-ID: <20120329093427.GA2358@deviant.kiev.zoral.com.ua> In-Reply-To: <20120329091415.GA1316@reks> References: <20120327183440.GS2358@deviant.kiev.zoral.com.ua> <20120329091415.GA1316@reks>
next in thread | previous in thread | raw e-mail | index | archive | help
--KKlV3Q509gERURet Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. > >=20 > > 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. > >=20 > > Filesystem-specific implementations could greatly increase the performa= nce > > 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. >=20 > 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. >=20 > We should also return valid _PC_MIN_HOLE_SIZE (=3Dmnt_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 implementatio= n, at least it seems so from my reading. Currently I am more interested in the comments about the approach itself. >=20 > 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. --KKlV3Q509gERURet Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk90LKMACgkQC3+MBN1Mb4jFPACfXjnd9s3pk6nr/fDeDszTt7B/ SakAoM+v6PqHuykiRqoRjoOsB1u+q30N =foX6 -----END PGP SIGNATURE----- --KKlV3Q509gERURet--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120329093427.GA2358>