[linux-mm-cc] compcache-0.5pre1 release

[Nitin Gupta]

On Mon, Dec 29, 2008 at 8:35 PM, John McCabe-Dansted <gmatht at gmail.com> wrote:
> On Sun, Dec 28, 2008 at 10:36 PM, John McCabe-Dansted <gmatht at gmail.com> wrote:
>> FYI, I have attached another patch. This fixes the above error, but
>> there is still another bug. AFAICT now all page reads report that
>> decompression failed. I do not know what causes this bug, and this
>> patch is still  filled with extra pr_info("Debug ...") lines to help
>> my try to track this down. I'll look into this as time permits.
>
> OK, fixed this. This patch still doesn't attempt to support 64bit and
> leads to crashes even on 32bit... I don't know if this is a new bug in
> my code or yours, I remember your original code being crashy as well,
> but I blamed this on the swap write errors.
>
> If I swapon, it may crash on heavy load, and also
>
> # tar -c / > /dev/ramzswap0
> tar: Removing leading `/' from member names
> tar: Removing leading `/' from hard link targets
> <then it just hangs>
>
> #tar -c / |  gzip > /dev/ramzswap0
> OTOH seems stable, as does
> sudo dd if=/dev/zero of=/dev/ramzswap0
>
>
> Also, why do we initialize the swap in the module? Why don't we just
> run mkswap /dev/ramzswap0?
>

Any write to /dev/ramzswap0 from userspace will lead to crash. Writing
compression blk device that supports arbitrary R/W is harder to write
and is useless for our purpose. We just need to handle swap requests
the way we do currently.

I also don't understand how you are getting these crashes on
32/64-bit. Try latest SVN - it should run just fine (it now also
handles case for uncompressible pages).

Nitin