From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?B?SsO2cm4=?= Engel Subject: Re: [RFC][PATCH] Implement SEEK_HOLE/SEEK_DATA Date: Thu, 29 Nov 2007 05:14:46 +0100 Message-ID: <20071129041445.GB11841@lazybastard.org> References: <20071128200206.GB3977@dhcp243-37.rdu.redhat.com> <1196290614.18231.17.camel@entropy> <20071128233959.GF4913@webber.adilger.int> <20071128234842.GA8664@lazybastard.org> <20071129032711.GI4913@webber.adilger.int> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: =?utf-8?B?SsO2cm4=?= Engel , Nicholas Miell , Josef Bacik , linux-fsdevel@vger.kernel.org, Andreas Dilger To: Andreas Dilger Return-path: Received: from lazybastard.de ([212.112.238.170]:35012 "EHLO longford.lazybastard.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752648AbXK2EUE (ORCPT ); Wed, 28 Nov 2007 23:20:04 -0500 Content-Disposition: inline In-Reply-To: <20071129032711.GI4913@webber.adilger.int> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Wed, 28 November 2007 20:27:11 -0700, Andreas Dilger wrote: > On Nov 29, 2007 00:48 +0100, J=C3=B6rn Engel wrote: > > I didn't follow the discussion much, since it didn't appear to suit > > logfs too well. In a nutshell, logfs is purely block-based, prepen= ds > > every block with a header, may compress blocks and packs them as ti= ghtly > > as possible (byte alignment). >=20 > The FIEMAP interface in some ways well suited to your needs, because = it > uses byte offsets instead of FIBMAP, which uses block offsets. I now= see > that one hole in the specification is that your physical extent is no= t the > same length as the logical extent that the data represents. >=20 > I'm not sure that is in itself a reason not to use FIEMAP. There is = already > a provision for logical extents that do not map directly to the physi= cal > layout (i.e. FIEMAP_EXTENT_NO_DIRECT flag on the extent). In the cas= e of > logfs, the extent fe_length would represent the logical length of the= data > that the extent covers, fe_offset is the start of the physical extent= , and > FIEMAP_EXTENT_NO_DIRECT indicates that this extent cannot be directly= mapped. > This is useful for applications like LILO that would otherwise assume= the > physical offset can be used to access the data from the block device. That could work. There really isn't a reason for any application to mess with physical locations when dealing with logfs. > SEEK_HOLE/SEEK_DATA only provides a fraction of the useful informatio= n > that FIEMAP does. It won't give users or developers any information = about > the on disk layout (which is quite important for knowing if allocatio= n > algorithms are good). It has the advantage of being easy to use. My completely untested attempt at a copy loop is just 14 lines. Add some error handling and i= t should still be quite small. off_t data_ofs, hole_ofs; long count; for (data_ofs =3D hole_ofs =3D 0; ; ) { if (data_ofs >=3D hole_ofs) { data_ofs =3D llseek(in_fd, data_ofs, SEEK_DATA); hole_ofs =3D llseek(in_fd, data_ofs, SEEK_HOLE); } count =3D splice(in_fd, &data_ofs, out_fd, &data_ofs, hole_ofs - data_ofs, 0); if (count =3D=3D 0) break; data_ofs +=3D count; } And when trying to optimize away some of the system calls, my personal preference would be to teach splice about seek_hole and seek_data and just splice the complete file range in one go. J=C3=B6rn --=20 "Security vulnerabilities are here to stay." -- Scott Culp, Manager of the Microsoft Security Response Center, 2001 - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html