[Fedora-livecd-list] squashfs -- anyone have a pristine tree?

Toshio Kuratomi toshio at tiki-lounge.com
Mon Apr 10 21:40:23 UTC 2006


On Mon, 2006-04-10 at 11:18 -0700, Jane Dogalt wrote:
> --- Jeremy Katz <katzj at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-livecd-list/attachments/20060410/8d6d04b7/attachment.sig>


More information about the Fedora-livecd-list mailing list