Alexander E. Patrakov wrote:
<snip good description>
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.
IMO, the compression ratio seems to be fine with zlib. The last iso we
made was 380MB I belive, with 150MB of it being sources. 230MB isn't
bad for a lfs system with over 150 packages (152 dirs in truks /packages
dir). But I don't know LZMA so well, so maybe it is faster/better.
4) Needed kernel patches:
Method 1: unionfs, squashfs
Method 2: none
It doesn't bother me patching the kernel. We still will have to patch
it for reiser4 support anyways.
5) If I download a 100M file and erase it, the space available in
tmpfs will:
For building LFS, this shouldn't be too big of a problem, if I
understand correctly. Actually, now that I think about it more, what is
there really on the cd what will grow in size? LFS will be built on a
partition on the hdd, so theoretically the only change to the LiveCD
system is adding the lfs user and changing the bash startup files.
Also, just to make sure I understand correctly, the space doesn't become
available because it is recorded in /dev/loop1 and can't really be
erased or because of compression?
7) If I want to undelete that 100M file:
Method 1: impossible
Method 2: ext2undel works
Interesting. I don't know how this would be helpful on the LFS LiveCD
though. Any files that one would want to undelete are on the hdd
partition that LFS is being built on. This doesn't have anything to do
with unionfs/dm.
8) Warnings during the boot process:
Method 1: "find" complains about -noleaf while building the list of
timezones
Method 2: none
Does this cause any problems besides a warning?
9) Glibc testsuite in Chapter 5:
Solved as you said, so we can forget about it.
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.
I haven't been on the LiveCD team that long, so I can only talk about
what I remember (I don't remember oops problems). Unionfs has a few
small patches to fix 5 lines total. I just checked and see 2 new
releases (1.1.0 and 1.1.1) from October. Not sure what other problems
you are having with unionfs (as you said above), maybe it is fixed in
the new release.
I am not sure which direction we should take. I never thought unionfs
so bad, and there aren't (IMO) any huge advantages that we would gain
from changing to dm. That doesn't mean I completely rule out dm
though. We will see what the other devs have to say.
Thank you for your excellent analysis Alexander. :)
Justin
--
http://linuxfromscratch.org/mailman/listinfo/livecd
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
