This is the mail archive of the
ecos-patches@sources.redhat.com
mailing list for the eCos project.
Re: Pooled memory allocation for JFFS2
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