User space filesystems for L4Linux

[Uwe Geuder]

Hi!

On Fri, 11 Jul 2014 00:16:57 +0300, I wrote:

> The next step is compression. Both ramdisks and cpio archives can be
> compressed, again Linux can dynamically recognize that and uncompress
> before usage. (I have only tested cpio.gz so far, but I understand
> also disk images work and both faster lzo and more aggressive bzip2
> and xz are supported.)

Just for completeness I might mention that I now have also tested
cpio.lzo and cpio.bz2.

Both worked as expected. Lzo results in bigger image than gz, so
loading is slower, but uncompressing is faster than gz. The net gain
was negative in my case, gzip winning the race.

For bzip2 it was the opposite. A smaller image that can be loaded
faster, but needs longer to uncompress. The net gain was strongly
negative, so gzip solution still unbeaten.

After doing the comparison if found
http://pokecraft.first-world.info/wiki/Quick_Benchmark:_Gzip_vs_Bzip2_vs_LZMA_vs_XZ_vs_LZ4_vs_LZO ,
which taught me that the compression level has major effect. I had
run everything with -9 wrongly assuming that the main penalty of using
a high level is during compression (on the host, where I don't care
that much). From looking at those tables it appears that lzma -e -9
might achieve best boot time results. Or maybe -7 because otherwise I
might run out of memory during decompression. Let's see whether I can
find time to verify this estimation.

Most interesting from L4 perspective though is the fact that xz
decompression in L4Linux failed with an L4 error. I think I will post
the details to this list soon under a more suitable subject.

No, I have not used the options froms scripts/xz_wrap.sh because I
found it only after my testing. Of course different options might
result in non-optimal results, but I don't see how they could cause
that crash.

Regards,

Uwe Geuder
Nomovok Ltd.
Tampere, Finland
uwe.gxuder at nomovok.com (bot test: humans correct 1 obvious spelling error)