e2dis status update
>>>>> Steve McIntyre <steve@einval.com> writes:
>>>>> Ivan Shmakov wrote:
>> It was my understanding that Jigdo's .template cannot associate one
>> SHA-1 with such a non-contiguous chunk.
> Correct. That could be added as a feature, maybe - we could add
> extent-mapping.
The format seemed to me a bit ad hoc, so I've used SQLite3
instead.
The news is that both the disassembly (e2dis) and reassembly
(imrt) tools are now working (but read below for a caution) and
available from their public Git repository [1] at Gitorious!
[1] https://gitorious.org/e2dis/e2dis-devel
The performance of e2dis itself is apparently out of concern:
$ tail -n7 -- \
+nohup.out-1314862288 \
+nohup.out-1314881076
==> +nohup.out-1314862288 <==
I: inode: ino=393214, blocks=0, size=0
I: inode: ino=393215, blocks=0, size=0
I: inode: ino=393216, blocks=0, size=0
I: filesystem: payload_blocks=286523
sqlite3_exec (db, `END;', 0, 0, => `(null)') => 0
108.10user 10.19system 2:34.25elapsed 76%CPU (0avgtext+0avgdata 0maxresident)k
8395040inputs+72outputs (7major+1229minor)pagefaults 0swaps
==> +nohup.out-1314881076 <==
I: inode: ino=131071, blocks=0, size=0
I: inode: ino=131072, blocks=0, size=0
I: filesystem: payload_blocks=476432
Unknown code ext2 47 #0 for Payload blocks bitmap
Unknown code ext2 47 #0 for block bitmap for /dev/stdin
24.90user 3.90system 0:36.49elapsed 78%CPU (0avgtext+0avgdata 0maxresident)k
1044670inputs+32outputs (3major+1203minor)pagefaults 0swaps
$
The respecitve filesystems' sizes are as follows:
Filesystem 1K-blocks Used Available Use%
FILESYSTEM-1 3096336 1146168 1792884 39%
FILESYSTEM-2 507748 477089 4445 100%
And the sizes of the resulting indices are:
11054080 (3.5%) 0bca32a2-d46c-11e0-935b-001966aaa0b6.db
6078464 (1.2%) 105f858e-d498-11e0-935b-001966aaa0b6.db
(No data in the indices beyond, roughly, the offsets, the
hashes, and the inode numbers.)
Unfortunately, the performance of the image reassembly tool
(imrt) is extremly poor for the filesystems of more than a few
MiB's size. (And it seems that there may be subtle bugs, too.)
As with jigdo-file(1), imrt doesn't rely on filenames, and
instead “guesses” the output chunks the files passed to it
correspond by comparing the hashes (SHA-1 and SHA256 as of
a726267a.) However, such a comparison is currently implemented
in a straightforward yet suboptimal (as in: totally dumb) way,
leading to the problem.
I still hope to rewrite the respective part of the code and
reach a better reassembly rate, and will report to the list.
> I'm also thinking of adding code to say "this file from within this
> .deb", so we could maybe support jigdo for live images too...
That doesn't seem to be necessary: jigdo-file(1) relies on
hashes, not filenames; and jigdo-lite(1) could be taught to
recognize .deb's and unpack them into a temporary directory, for
jigdo-file(1) to pick up the contents.
--
FSF associate member #7257 Coming soon: Software Freedom Day
http://mail.sf-day.org/lists/listinfo/ planning-ru (ru), sfd-discuss (en)
Reply to: