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

[Toshio Kuratomi]

On Mon, 2006-04-10 at 18:26 -0700, Jane Dogalt wrote:
> --- Toshio Kuratomi <toshio at tiki-lounge.com> wrote:
> 
> > On Mon, 2006-04-10 at 11:18 -0700, Jane Dogalt wrote:
> > 
> > > 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.
> 
Sure, but we do need to worry about it working.  If zisofs has
significant features that squashfs lacks and vice versa then I can see
supporting both at this stage.  If not, then keeping a filesystem that
provides no real advantages means we have a code path in kadischi that
few, if any, developers are going to want to test thoroughly and bugfix.
This leads to non-working code later.

> Obviously ext2 is never going to beat squashfs on size.  One would guess
> uncompressed it would win on speed.
You'd want to benchmark this -- CDRoms are pretty slow media so it could
be that squashfs is faster for our use case as well.

>   Clearly at the moment it's the only one
> that supports xattrs.  
Yep.  And If someone wants to make ext2 images work with kadischi, the
code to support multiple filesystems can be written to support ext2 and
squashfs.  If it's still applicable, it can be revived from the cvs
repository.  Depending on how long before someone adds it, it may be
that all of the code has gone through several rewrites since then.

> Then throw in that you can (I think) run it on top of
> cloop as yet another option.
> 
Hmmm... cloop's source repository is currently down so I cna't look itno
it:
  http://developer.linuxtag.net/knoppix/sources/

Since it's not in the mainline kernel, someone has to package it for
Fedora Extras.

I'm not sure that cloop by itself will provide us with something better
than squashfs.  But if cloop + ext2 is the best way to get compression
and SELinux, then it would make sense for now.

OTOH, someone may decide to add xattrs to squashfs in which case I'd ask
again, what does ext2 do better than squashfs?

> 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 agree that having options for tradeoffs make sense.  And I think that
in the absence of xattrs in squashfs, ext2's SELinux support is a big
feature that can be seen in this light.  I haven't seen the same kind of
compelling reason for zisofs.  To the end-user booting the LiveCD the
non-loopback case isn't going to be visible.  To the creator, kadischi
hides the complexity for either case.  Most developers wanting to peer
inside the ISO from outside the LiveCD environment are going to be able
to mount the filesystem and will be willing to do that for the superior
performance that squashfs gives.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/livecd/attachments/20060410/5a5b0cc0/attachment.bin