This mail is a comparison of two methods of achieving a fully-writable CD.
Method 1, currently in trunk:
The ISO image contains a .root.sqfs file that is a read-only squashfs
filesystem image. Squashfs is used because of compression. Unionfs is
used to "union" the filesystem contents with the contents of a tmpfs
mount. Then this unionfs is used as a root filesystem.
Method 2, currently in the "dm" branch:
The ZISO image contains a root.ext2 file that is an initial snapshot of
good old ext2 filesystem. A loop device /dev/loop0 is attached to this
file. Another loop device, /dev/loop1, is attached to a huge sparse file
in tmpfs. The "snapshot" device-mapper target is used to create the
/dev/mapper/lfs-cd node out of those two loop devices. Its initial
contents is the same as that of /dev/loop0. /dev/loop1 contains a log of
changes. This /dev/mapper/lfs-cd node is then mounted read-write as ext2
filesystem.
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.
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.
3) Tmpfs contains:
Method 1: changed files
Method 2: changed sectors of the original ext2 image
4) Needed kernel patches:
Method 1: unionfs, squashfs
Method 2: none
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
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
7) If I want to undelete that 100M file:
Method 1: impossible
Method 2: ext2undel works
8) Warnings during the boot process:
Method 1: "find" complains about -noleaf while building the list of
timezones
Method 2: none
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
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.
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/livecd
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
