linuxcompressed-devel

[lc-devel] [PATCH] 2.4.18-0.23pre5

[Rodrigo S. de C. <rc...@im...>]

This patch features the support for LZO compression algorithm added
back.

There's also a new /proc entry showing what's going on inside the
compressed cache. This entry (comp_cache_hist) displays the free space
histogram for all compressed cache pages, besides how many fragments
are stored in these pages. Very useful data.

Some bugs were fixed. In particular, a bug that was hit under UML
which could cause FS corruption and a bug in swap buffers management
that could hang the machine. About User Mode Linux, its author, Jeff
Dike, fixed a bug that I reported concerning swap addresses, so now we
can use compressed cache under UML (use version 2.4.18-30um or later).

This patch also features our kernel parameter (compsize=) which
accepts input in the format "mem=" does (for example, you can append
"compsize=16M"). Note, however, that /proc/sys/vm/comp_cache/size is
still a number of memory pages.

More details:
http://sourceforge.net/project/shownotes.php?release_id=48824

Download:
http://prdownloads.sourceforge.net/linuxcompressed/patch-comp-cache-2.4.18-0.23pre5.bz2?download
- direct link
http://west.dl.sourceforge.net/sourceforge/linuxcompressed/patch-comp-cache-2.4.18-0.23pre5.bz2

-- 
Rodrigo S. de Castro <rc...@im...>

Re: [lc-devel] [PATCH] 2.4.18-0.23pre5

[Rodrigo S. de C. <rc...@im...>]

On Thu, May 30, 2002 at 10:02:18AM -0300, Rodrigo Souza de Castro wrote:
> In particular, a bug that was hit under UML which could cause FS
> corruption and a bug in swap buffers management that could hang the
> machine.

Sorry about that, but that was a wrong fix.

I noticed that there had been an increase in IO performed when
compressed cache was enabled and after digging into the problem, the
culprit was this "fix" to the FS corruption bug under UML. I learned
better how buffers work and can say that this fix just papers over
that UML bug by forcing extra disk reads.

This morning I even introduced a checksum for compressed data to
doublecheck if we were returning sane data. My conclusion: there is no
bug in our code regarding this IO corruption problem under UML (that's
likely the reason we can't hit this corrupton bug on a real machine).

I will back out this "fix", so we cannot use UML until it gets
fixed. Although I can't reproduce this bug on vanilla under UML, I've
already reported a reproducible bug (running dbench) that corrupts UML
filesystem, even on a vanilla kernel.

-- 
Rodrigo S. de Castro <rc...@im...>