[Fedora-livecd-list] livecd-creator proposal for compression option

[Bruno Wolff III]

On Thu, Jun 10, 2010 at 22:20:33 -0700,
  Jasper Hartline <jasper.hartline at gmail.com> wrote:
> 
> I am not sure of the current benchmarks of disk I/O related data
> which depicts any significant advantage over mksquashfs using zlib or
> mksquashfs using lzma.
> Do you have some benchmarks you can throw our way?

Not yet. I would expect it to be better because of the better compression.
But whether that really helps or not depends on typcial access patterns.

> 400 MB is an insignificant gain in space saving to livecd-creator
> target images, and you fail to
> provide the actual uncompressed original sizes and final size using
> mksquashfs w/ lzma.
> This is insignificant and cannot be readily applied to any single scenario.

400 megabytes is not insignificant. I had to drop a rtelatively popular
first person shooter from the games spin because I needed about 150 megabytes.
(There was a lot of tweaking near the end of the desktop spin which the
games spin derives from, so the amount I was short varied at the end of
the cycle. But I can tell you that 400 megabytes is enough to include at
least two relatively large games on the spin.)

> Just so you understand what I am getting at, a target ISO of 60MB
> of a custom LiveCD I built, only shrank 10MB to 50MB using mksquashfs w/ lzma.
> This is using the most minimal set of packages one could.

At least one of the livecd images was pretty tight. 50 MB of compressed
space can be important in that case. For the spins that fit easily on
their target media, it isn't a big deal.

> Where are you getting 400MB from? Because, that is not what I revealed
> in my testing.
> 60 to 50MB is more than 10%, so you are saying the larger it gets the
> worse space savings you get..

The games spin is just under 4 GB. A 10% savings there is approximately
400 MB.


> that is totally outrageous that you believe this is beneficial but not
> something like adding 924K syslinux to the base DVD which benefits
> many many people when they want to build a LiveCD with just the base
> DVD as a repository source. Interesting that we are so enveloped in

I didn't say it was important to some people, just not to me (compared to
other things I can work on). I use large custom usb live images and maintain
the games spin, and space savings are important to me, so I am willing to work
on that.

> ourselves we only see importance in what is as you said
> > You are free to focus on what is important to you. I plan to focus at
> > least some of my resources on what is important to me.
> 
> Try that more. 400MB is worse than 50 to 60MB, at more than 10%.
> mksquashfs w/lzma makes the gain worse, when the targets get larger.

The above statement makes no sense. Please try rewriting it if you want to
persue that argument.

> > It will in fact allow a few more well known games to be included in the
> > games spin. That is mostly a marketting tool, bur being able to show off
> > some more games is nice. It also effects people who want to run live usb
> > images and want to limit the amount of space they use.
> The amount of space is already limited, it;s already a SquashFS with
> no more than 10% savings.

And that extra 10% let's me put a couple of more relatively large games
on the games spin. It also helps with making custom spins with even more
games targetting an 8GB usb drive.

> >> Maybe someone will disagree or perhaps some gamers will comment on
> >> your post instead.
> >
> > It's really not a gamer issue. It is an enhancement in to the capabilities
> > of live images, in that people will have the option to save additional
> > space if they want. Probably lzma will be best to enable by default, but
> > that will require most testing to see.
> I think you're wasting your time trying this because it will be a
> while before SquashFS w/ lzma is introduced
> upstream for general use, and possibly longer before Fedora enables it
> or puts it into stock.
> Have fun.

It's my time to waste.

If lzma support for squashfs gets into the 2.6.36 kernel it will be supported
in Fedora. (Though maybe not at the F14 release.) Whether or not it gets
included in 2.6.36 is iffy. Phillip needs some time to rework his previous
patches into a form acceptible to Linus. He actually has patches in his
own git branch, but I have tested them. Nor do I know if they are improved
or if they are just the patches that were rejected.