Re: Pooled memory allocation for JFFS2

[David Woodhouse <dwmw2 at infradead dot org>]

On Sat, 22 Nov 2003, Thomas Koeller wrote:

> And finally, a few general remarks about compression from a user's perspective:
> Having the compression inside the file system may be convenient, but it also
> prevents me from exercising much control over it. Neither can I choose a particular
> compression method that suits my kind of data, nor can I selectively enable
> compression only for data for which this is worthwile.

True. In the Linux world using transparent compression means that we don't 
have to hack compression into _every_ userspace program. In eCos that's 
not so much of an issue -- disabling compression in the fs does make 
sense. Although I do intend to allow the user to disable compression, or 
specify that only certain compression algorithms to be attempted, on a 
per-inode basis -- that's quite simple to do, and there's already space in 
the node header allocated for it.

> And then, the results of compressing data in small chunks tend to be
> inferior to those obtained by compressing the entire amount of data at
> once. 

Yeah -- but the results of writing data to JFFS2 in small chunks sucks in 
comparison with the result of writing in pages -- at least till it gets 
merged during garbage collection.

> Finally, the compression seems to cause problems within the FS itself
> (why was it that we need five spare erase blocks at any point in time? I
> vaguely remember the reasoning was somehow related to the possibility of
> compressed data expanding under garbage collection).

That's one of the theoretical ways in which stuff can expand on GC. In 
fact it's purely theoretical -- again, the 70-odd byte node header is far 
more tangible ;)
 
> For all those reasons, a developer writing software for small resource-constrained
> embedded targets will probably almost always be better off doing any required
> compression by himself instead of relying on the FS' internal compression. File
> systems and compressors are two unrelated functions, and I highly value modularity.
> If compression had be left out of the FS, the code would probably have been simpler
> and easier to maintain. Just my opinion, of course.

I'm perfectly happy for it to optional. It makes a lot less sense in eCos
than in Linux. In fact, compression really hasn't caused any maintenance
problems; it's been the simplest part of the fs.

-- 
dwmw2