Re: e2dis: a Jigdo-like tool for Ext2+ FS images
>>>>> Steve McIntyre <email@example.com> writes:
>>>>> Ivan Shmakov wrote:
BTW, the primary Git repository for the project is now located
The most notable improvement that I made recently is the message
>> 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.
> That would be absolutely the best way to go, yes. I added the code
> into mkisofs and genisoimage, but it has since been abstracted out
> into libjte, part of the cdrkit package in Debian.
I'm yet to take a look at the code, but do I understand it
correctly that Jigdo's .template only allows for a file (as
identified by the SHA-1 digest of its contents) to be associated
with a contiguous part of the destination image?
Such an approach is hardly applicable to Ext2+ FS images.
Consider, e. g.:
$ /sbin/debugfs +b21e37e0-c722-11e0-9094-001966aaa0b6.ext2
debugfs 1.41.12 (17-May-2010)
debugfs: stat <12>
Inode: 12 Type: regular Mode: 0644 Flags: 0x0
Generation: 3178327445 Version: 0x00000000
User: 0 Group: 0 Size: 16384
File ACL: 0 Directory ACL: 0
Links: 1 Blockcount: 34
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x4e48e9c1 -- Mon Aug 15 09:41:21 2011
atime: 0x4e48e9c1 -- Mon Aug 15 09:41:21 2011
mtime: 0x4e48e9c1 -- Mon Aug 15 09:41:21 2011
(0-11):21-32, (IND):33, (12-15):34-37
There, the file's contents in two parts: one occupies image's
blocks 21 to 32, inclusive, and the other one 34 to 37,
It was my understanding that Jigdo's .template cannot associate
one SHA-1 with such a non-contiguous chunk.
FSF associate member #7257