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

[Jane Dogalt]

--- Toshio Kuratomi <toshio at tiki-lounge.com> wrote:

> 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.

see below

> 
> > 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 suppose my opinion is that it is a trivial complexity addition, one which
kadischi currently possesses (though it could be 'cleaner'), and why revisit
later, when we can just clean up and extend what is currently there?

I don't think kadischi is yet in any kind of state where we should be worried
too much about "the" optimal solution.  I think kadischi is still barely in the
experimental state where we need to find out what "the" optimal solution is, or
whether or not the optimal solution is to have a trivial additional user
option, which facilitates the easy evaluation and comparison of various
alternatives.

Obviously ext2 is never going to beat squashfs on size.  One would guess
uncompressed it would win on speed.  Clearly at the moment it's the only one
that supports xattrs.  Then throw in that you can (I think) run it on top of
cloop as yet another option.

I think that kadischi should be a flexible tool that is widely used.  I.e. we
should be seeing at least dozens of publicized kadischi-generated livecd
'tools' out there, just like one can see dozens of knoppix derivatives.  To be
that, I think we need to give the user some options for tradeoffs that may make
sense in their particular case.  Some may need selinux and can live with less
compression, others may want to use squashfs for size, and still others may
want to use isofs and/or zisofs in order to allow system files to be directly
visibly on the cdrom (ok, so I just added more complexity to not throw away the
non-loopback mounted case, but you know what- I think end-users will appreciate
the choice).


> 
> > 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.

Ugly is ... I'll hold my forked tongue on that one for now ;)

The advantages I've laid out above.  Give the user choice.  Make it easy to
plug in, test, and compare supertinycramfs-7.0 when it gets invented next year.

> 
> > 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.

Thanks.  I'm just throwing out ideas here.  Code beauty lies in the eye of the
programmer.  I agree that X autodetection and sane firewall config options are
a higher priority than this.  My vision is for the months ahead here, not just
tomorrow and next week.

-jdog


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com