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?
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.
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. :) )
4) Needed kernel patches:
Method 1: unionfs, squashfs
Method 2: none
Yes, not having to patch the kernel is nice, but I'm not sure that I see
patching it as a problem either.
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.
6) If I download another 100M file and erase it, the space available in
tmpfs will:
Method 1: return to the previous level
Method 2: not change
Somewhat better, but Method 1 still sounds preferable.
7) If I want to undelete that 100M file:
Method 1: impossible
Method 2: ext2undel works
Nice feature, but not really on my list of top priorities.
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?
9) Glibc testsuite in Chapter 5:
Method 1: used to fail, worked around by mounting a tmpfs on /tmp
Method 2: passes without any quirks
Nice, not critical, IMHO.
10) Bug history:
Method 1: Unionfs used to oops the kernel. None of the official releases
were good enough without additional patches. We do use a patch which
seems to fix most of problems.
Method 2: both zisofs and "snapshot" device mapper target are in the
official kernel for a long time. dm-snapshot is well-tested by LVM
users, and actually is the resommended method of taking backups from a
live system.
Yes, and if I gather this one seems to be your main impetus for trying
device mapper, correct? A good reason, too. One nice thing about unionfs
is that the devs are *very* active and easy to work with. :)
My main concern is that this becomes a rather convoluted way of
achieving what we already have working. It appears to be a much more
complicated way of setting up writability on the CD system. On the other
hand, I'd gladly use it and work at understanding the concept better if
you can show quantitatively (better performance, compression, etc.) that
this is a better solution. If it's the same or worse I'd rather just
stick with what we have, buggy history or no.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/livecd
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
