Go to the first, previous, next, last section, table of contents.


Why was e2compr written?

When I (Antoine) got my laptop and installed Linux on it, it was pretty obvious that the hard drive was too small (240MB) to get a complete installation of all the tools I needed, while still having a DOS partition (games for my children) and some space for users. Buying a new drive would have been quite expensive and not very practical for a laptop.

That's why I immediately looked for tools that could do on-the-fly compression and decompression. I installed zlibc and tcx, and used them for a while. Though these are nice tools, there are some limitations. For instance, you can't write to compressed files through zlibc; and tcx works only for executables. Of course these are minor problems. These tools are doing what they were written for. I used them for some months, and one day I reinstalled some packages on my system: I realised that each time I reinstalled something, I had to compress by hand the manuals, the binaries if I wanted to.... I found this very painful, and I started to dream about a file system that would do it in a transparent way. What I was looking for was a system that could provide write access to compressed files, and for which I wouldn't need to compress newly installed files myself.

Someone alerted me to the existence of DouBle by Jean-Marc Verbavatz (ftp://achaz.saclay.cea.fr/pub/double/). I got it and looked at how it did its work. There was however one thing that made me feel a little insecure: administrative data is compressed as well. This means that if your system crashes you may lose much more than a few blocks. Maybe I am a little over-anxious, but I couldn't bear the idea of my son pressing the power off button while I was working. I felt this was a major problem for me. I was only ready to use DouBle instead of zlibc for files I could easily recover. [pjm: I can confirm that a filesystem compressed with DouBle can run into big problems if the machine is powered off in the middle of a write. If you lose the first DouBle cluster of the partition then you might as well say goodbye to the whole filesystem. Unlike e2compr, there wasn't even any error recovery means except to read the source code until you can work out the file format and then use a raw disk editor.]

I then started to think about what I would really like to have on my machine. The result is the e2compr patch for which you are now reading the documentation. The ideal tools would meet the following requirements:

  1. automatic compression
  2. automatic decompression
  3. file access in both read and write modes
  4. flexible configuration
  5. secure

From the 3 tools mentioned above, DouBle is probably the best one. It meets requirements a, b, c and d. Unfortunately I can't live with the idea that inodes are blindly compressed. Both tcx and zlibc meet requirements b and e. I don't consider they are very flexible because there is no way to tune them. Note also that they will both fail to decompress data on a completely full file system.

E2compr obviously meets requirements a, b, c, d and e. And that's why I wrote it.


Go to the first, previous, next, last section, table of contents.