On Wed, 28 November 2007 20:27:11 -0700, Andreas Dilger wrote:
quoted text
> On Nov 29, 2007  00:48 +0100, Jörn 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, prepends
> > every block with a header, may compress blocks and packs them as tightly
> > as possible (byte alignment).
> 
> 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 not the
> same length as the logical extent that the data represents.
> 
> 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 physical
> layout (i.e. FIEMAP_EXTENT_NO_DIRECT flag on the extent).  In the case 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.

quoted text
> SEEK_HOLE/SEEK_DATA only provides a fraction of the useful information
> that FIEMAP does.  It won't give users or developers any information about
> the on disk layout (which is quite important for knowing if allocation
> 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 it
should still be quite small.

off_t data_ofs, hole_ofs;
long count;

for (data_ofs = hole_ofs = 0; ; ) {
	if (data_ofs >= hole_ofs) {
		data_ofs = llseek(in_fd, data_ofs, SEEK_DATA);
		hole_ofs = llseek(in_fd, data_ofs, SEEK_HOLE);
	}
	count = splice(in_fd, &data_ofs, out_fd, &data_ofs,
			hole_ofs - data_ofs, 0);
	if (count == 0)
		break;
	data_ofs += 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örn

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