
Dear tester,

This is e2compr version 0.3.  It is considered in alpha stage
(i.e. not ready for general distribution).  People have been using
this and previous releases without too much problem, but you should be
aware of the following limitations:

  - e2uncompress (or e2compress -d) is not done.  The two aims of
    e2uncompress are:

      - to help in kernel development

      - to allow people to access compressed files even from a kernel
        that doesn't include the e2compression patch.

  - The patched e2fsck gives errors for its byte-swapping feature.
    This may be of concern to users of non-x86 architectures.

  - Write access through mmap() isn't available for e2compressed
    files.  I haven't run into this limitation yet in personal use,
    but it will be an issue for some uses.  DouBle may provide the
    functionality you want here: dd a file, create a DouBle device on
    that file, and either mmap directly to the DouBle device or create
    a filesystem on the DouBle device and mmap to a file on that
    filesystem.

                              ***

Before you go on, I want to point out that there should be absolutely
(with usual precautions) no risk for your file system.  Files that are
not marked with the EXT2_COMPR_FL flag are handled exactly the same
way they were before the patch.  The patch only adds code to be
executed for files that do have this flag set.  Note that
administrative data (e.g. inodes, the superblock and its copies,
directory blocks, bitmaps) are stored on disk in the same way as they
were before the patch, so in theory the most you stand to lose is any
file you compress that isn't also stored elsewhere.  (Of course, if
there's a bug that brings the system to a halt, or scribbles on random
kernel data structures or does other dammage, then you could lose
more; but as far as I know, no-one's experienced that since the patch was
first released.)

                              ***

Things for You to Do
====================

1) Read this and the HOWTO, FAQ and INSTALL files, and send any
corrections, clarifications, additions etc.

2) Install the patch.  If you have any difficulties (possibly
resulting from a misunderstanding of the instructions), write back, so
that the instructions may be improved.  Everybody, without particular
skills about kernel hacking, should be able to install the patch.

3) Try to break the code.  Imagine everything horrible you can and try
it.  Try to make files that have holes, that have some part that can
compress well, some other parts that won't compress.  Make lots of
random accesses.  Try to access files both in read and write mode by
many processes at the same time until you lock the system...

Send bug reports, even for non-reproducible problems.  Quite possibly
your machine's just flakey or you've made one of those errors that we
like to think only newbies and clueless people make; but it's also
possible that there's a subtle bug somewhere.  If you do send a
non-reproducible bug, please also comment on your machine's general
reliability (how often you see Segmentation Fault or Oops).

I'd also like to hear if you have no problems after some time.

Of course, patches and/or testing utilities are welcome.  Don't
hesitate to send me code.  I am also interested in collecting
benchmark results.

If you want to see a particular compression algorithm, send it to me.
I will try to add it provided there is a reason someone would want to
use it in preference to one of the ones already provided (e.g. speed
of either compression or decompression, compression ratio, freedom of
patent restrictions).

I would also really appreciate if some of you could just read the
code and say if there are any obvious errors.  The code is commented
for easier reading.

Report everything to the following address:

	<reiter@netspace.net.au>

(or comp.os.linux.development.system if you prefer, though e-mail is
probably more appropriate for most things, and I'm more likely to
receive it).

                              ***

Thanks for your interest, and happy testing.
