[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: e2dis: a Jigdo-like tool for Ext2+ FS images

>>>>> Adam Borowski <kilobyte@angband.pl> writes:
>>>>> On Sun, Aug 14, 2011 at 03:07:24PM +0700, Ivan Shmakov wrote:

 >> BTW, I've just announced [1] the availability of the code which
 >> (given some attention and care) may be turned into a Jigdo-like
 >> suite for Ext2+ FS images.

 >> (The casuality of fragmentation on such filesystems greatly reduces
 >> the applicability of the FS-agnostic Jigdo tool.)

 > It seems to me that if you instead physically reordered blocks,
 > actual data extents could be made contiguous, allowing use of
 > standard Jigdo.

	Thanks for the suggestion.

	Unfortunately, the Jigdo's assumption of the continuity of the
	blocks comprising a file covers the reassembly phase just as

	The blocks of an image may still be reordered to get the desired
	effect, but they'd have to be reordered back at the time of
	reassembly, thus requiring a separate relation (file) to do so.

	Perhaps, the ordering of the blocks on a filesystem can be
	altered (consistent with the service data of the filesystem
	itself) to remove fragmentation, but I'm not sure on that, and
	my limited knowledge of the Ext2FS library doesn't allow me to
	devise a way to do that.  (But I'd ask about it in linux-ext4@.)

	… On the other hand, the “chunk mapping” model I've used in the
	current version of the e2dis code is a superset of the model
	implemented by Jigdo.  Therefore, I don't think it'd be
	infeasible to implement Jigdo support in the image download and
	reassembly tool I'm planning to develop for e2dis.

	(BTW, I've posted a very basic image reassembly tool to
	alt.sources about three weeks ago [2].  It's not compatible with
	the format used by e2dis, though.)

[2] news:86zkk8xhh4.fsf@gray.siamics.net

 > (Of course, that might be not worth the extra effort...)

	Jigdo has to “discover” octet sequences on an image with
	hashing, which is computationally expensive.

	IIRC, Debian's genisoimage(1) was altered to prepare a Jigdo's
	.template file as part of the image generation, which is much
	more efficient.  I believe that a similar approach could be, and
	should be, used for the other filesystems as well.


 >> [1] http://thread.gmane.org/gmane.comp.file-systems.ext4/27269

FSF associate member #7257

Reply to: