From owner-freebsd-fs@FreeBSD.ORG Thu Mar 29 09:34:37 2012 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03A0D106566B for ; Thu, 29 Mar 2012 09:34:37 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 6D23B8FC16 for ; Thu, 29 Mar 2012 09:34:35 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q2T9YRTC079746; Thu, 29 Mar 2012 12:34:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q2T9YRrn094569; Thu, 29 Mar 2012 12:34:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q2T9YRp6094568; Thu, 29 Mar 2012 12:34:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 29 Mar 2012 12:34:27 +0300 From: Konstantin Belousov To: Gleb Kurtsou Message-ID: <20120329093427.GA2358@deviant.kiev.zoral.com.ua> References: <20120327183440.GS2358@deviant.kiev.zoral.com.ua> <20120329091415.GA1316@reks> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KKlV3Q509gERURet" Content-Disposition: inline In-Reply-To: <20120329091415.GA1316@reks> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: fs@freebsd.org Subject: Re: RFC: SEEK_HOLE/SEEK_DATA common implementation X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 09:34:37 -0000 --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--