[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: JFFS compression and hard links.

On Tue, 9 Jan 2001, Tim Riker wrote:

> I actually would like a user space compress tool and not to have
> "compress on the fly" support.

Omitting runtime compression will be compile-time option.

> This simplifies the model greatly and speeds up the normal write
> performance.

Flash writes are _slow_. Compression is relatively fast. I'd be
surprised if compressed writes didn't turn out to be generally faster
than uncompressed writes.

> The user space tool would need to be able to call a "compressed_write"
> on a live mounted filesystem, but this should not be much different
> than normal writes (which would be uncompressed).

Having a way for an application to get compressed nodes onto the flash at
runtime isn't going to be simple. At least, it's not going to be _clean_.
And that's what I care about.

> I'm not saying that transparent compression is a Bad Thing, just that it
> is not nearly as urgent and is significantly more difficult to do right.

It's urgent for me. I think it'll provide functionality sufficient for
most people, but that's why I'm asking here now. If people really want to
be able to disable runtime compression, that can be arranged.

So far, the only real disadvantage I can see of runtime compression is
that it's going to make my head hurt getting it right.

> There still are read/write issues like what happens when an app opens a
> very large compressed file and tries to rewrite a few bytes in the
> middle? I would say that the rewritten data gets stored as uncompressed
> inodes and the untouched compressed nodes stay where they were. This
> would require that the entire file be recompressed to retore it to
> optimal compression, but I can live with that.

You wouldn't need to recompress the whole file. You recompress only the
one or two nodes which were partially obsoleted by the new write, when you
come round to GC them anyway. S'not too much of a problem. And we'll
probably reduce the maximum node size too, to reduce it even further.


To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo@xxxxxxx.com