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

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

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