Jeremy Huntwork wrote:
Alexander E. Patrakov wrote:
Comparison:
1) Compression is applied to:
Method 1: filesystem, squashfs
Method 2: block device image, root.ext2, via zisofs. Any other
block-device compression method (e.g. cloop) will also work.
Advantages, disadvantages?
That's just a starting point. All of the below, except for bugs, are
consequences of (1).
2) Compression quality:
Method 1: zlib, applied to specially-designed filesystem. No
possbility to plug in a better (e.g. LZMA-based) compressor.
Method 2: zlib, applied to ext2 filesystem. Compression is a bit worse
because ext2 inodes have large size and no duplicate file detection
exists. If we move from zisofs to cloop, compression may become better.
I would like to see this quantified. The ability to plug in a another
compressor is nice, however, it's not very useful if the achieved
compression is the same or worse as what we currently have with squashfs.
minimal-blfs is 260 MB on squashfs and 271 MB (reducible to 267 MB by
running "make zeroes") on ext2 + zisofs. So we lose 2.6% due to ext2
complexity and 1.5% due to finally-unused ext2 blocks containing
non-zero data. But the zisofs compression process is way faster :)
cloop with best-quality 7z compression gives 262 MB without making
zeroes and 259 MB after making zeroes. But that means that the whole
compression process takes a bit less than 2.5 hours on my Celeron 1200.
3) Tmpfs contains:
Method 1: changed files
Method 2: changed sectors of the original ext2 image
Advantages, disadvantages? (I'm not sure if you expect some of these
points to be obvious, but having it spelled out is always helpful. :) )
Advantage: possibility to use a known bug-free filesystem with good
POSIX conformance. Disadvantage: there's no way to change the sector
from "changed" to "unchanged".
5) If I download a 100M file and erase it, the space available in
tmpfs will:
Method 1: return to the previous level
Method 2: decrease by 100M
Eek. Method 1 is definitely preferable on this point.
That's essentially the same as above.
8) Warnings during the boot process:
Method 1: "find" complains about -noleaf while building the list of
timezones
Method 2: none
Could the trouble with method 1 here not be worked around with a change
of commands used?
Yes, but isn't it too wrong to add that many workarounds?
1) for broken locking of modules (fixed now)
2) for glibc testsuite in Chapter 5
3) for the "find" command
4) for SAMBA that can't use sendfile() on unionfs
5) for openi18n testsuite (not done, would involve a tmpfs on /home).
As for your statement about complexity, this is only because I have not
documented the thing. In shell script, the setup is equivalent to the
following commands:
mount -i iso9660 $LFSCD /.cdrom
losetup /dev/loop0 /.cdrom/root.ext2
dd if=/dev/null of=/.tmpfs/.overlay seek=$(( $SIZE + $OVERHEAD ))
losetup /dev/loop1 /.tmpfs/.overlay
echo "0 $SIZE snapshot /dev/loop0 /dev/loop1 p 8" | \
dmsetup create lfs-cd
mount -t ext2 /dev/mapper/lfs-cd /.root
Nothing really complex, and there's only two commands more than for the
unionfs case.
With the unionfs case, we used a special filesystem (suqashfs) in order
to compress data. Its output is a read-only filesystem containing files
that we wrote to it. Then it is unioned with tmpfs, resuling in a
directory with writeable files.
With device mapper, the words are essentially the same. We use some
compressor (currently zisofs, but this is really easy to change) in
order to compress a single read-only file. Then we "union" it by means
of device-mapper with another file on tmpfs, the result is a block
device that can be mounted read-write.
In short, device-mapper "snapshot" target is a 1:1 replacement for the
"cowloop" module discussed earlier on this list.
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/livecd
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
