On Mon, 2006-04-10 at 11:18 -0700, Jane Dogalt wrote:
--- Jeremy Katz <katzj(a)redhat.com> wrote:
> Realistically, something like a --filesystem is the wrong approach. If
> squashfs is "right", then we should go down that route. Trying to
> encode the differences between squashfs and zisofs is the path to
> madness.
I respectfully disagree. An alternate suggestion would be to standardize on
filesystem images living on the iso. I.e. currently the choice is between a
'native' zisofs, and a squashfs image.
What is the advantage to the end
user of a zisofs image to the consumer
of the liveCD? The loopback complexity is handles by kadischi, so that
doesn't count. If there is no benefit, then it is a problem to maintain
the extra code path -- No active developers will be using (and therefore
testing) the sub-optimal code but users who do will uncover bugs that
then have to be fixed.
If say, the choice was between a zisofs
image, a squashfs image, and an ext2 image, then the user would have a nice set
of options. If in addition you go down the route of unionfs rather than
readonly-root and bindmounting, then you have a solution in which even selinux
is an option.
If ext2 gives us selinux capability and is generally better than
squashfs, then we can replace squashfs with ext2. If ext2 adds selinux
and is otherwise inferior to squashfs we can revisit maintaining two
filesystems.
I think you might have mentioned a problem with ext2 and cdrom 2k
block size.
I strongly suspect that if that is a problem, it's not a problem when you put
the ext2 filesystem on an image file which lives in an iso.
Having a case/switch statement use alternate tools to mk*fs the image, and then
having the initrd mount the right type of filesystem really isn't that ugly at
all.
Having to test and maintain a code path that provides no advantages is
the real problem. The fact that it is ugly is just icing on the cake.
To evangelize unionfs one step further (and competely orthogonal to
the rest of
this post), one could seperate the system image into two parts.
a) those parts that have been profiled as being used during boot and initial
login.
and
b) the rest.
Then if you have seperate fs images for those parts, and store them on the
cdrom, you should get improved boot speed, because of less seek thrashing
during boot. For more bonus, you get mkisofs to put the boot files on the
outer tracks, to possibly get that extra 5%.
I'll go ahead and do a proof of concept on this if no one else is interested.
Please do. I'm interested in seeing this in action but X autodetection
and modifying lokkit come before that on my schedule.
-Toshio