>>>>> Adam Borowski <kilob...@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
well.
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....@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
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/86aabc6sf5....@gray.siamics.net
