I'm running RH 5.0 + all official updates + linux-2.0.33 +
e2fscompr-0.3.6
and some hacks of my own to add LZO compression.
All the file systems are compressed with LZV1. All additions to files
and
new files happen uncompressed, and at night a cron job
compresses all the daily changes.
Now unless you do a 'chattr -m lzo +c filename' everything works just
fine.
What do I mean by fine? Well, the machine is used night and day by
several people who use it for surfing, applixware, gimp,
assortedX and svgalib games and programming. I enjoy
quake. If you do do a 'chattr -m lzo +c filename' the kernel oopses,
but that's
no problem, there are obviously bugs in my code.
e2fscompr comes with a utility e2compress which makes copies of the
source
files from the kernel, and links with them, to make a
user space version of what the kernel does. Peter Moulder (maintainer
of
e2fscompr) sez it's useful to use e2compress to test
ones code, 'cos then you don't have to reboot the machine all the time.
Ha. Ha.
I've been using e2compress to try debug my LZO code by running
'e2compress
-m lzo filename'. Sometimes it suceeds, sometimes
it doesn't. I've examined the execution in gdb and it certainly seems
to be doing
everything in user space.
But when it's done (either success or failure) the kernel will start
oopsing. Hey?
Yeah. One oops after another. Different process number every time.
Just like
the dcache is trashed. e2compress was running with normal user id.
How in principle is this possible?
chippo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu