[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: JFFS compression and hard links.
On Wed, 10 Jan 2001, Bjorn Wesen wrote:
> > We might as well bite the bullet and do dynamic compression right from the
> > start - people want it.
> Some people want it - I definitely don't want it and the iPAQ guys did not
> want it either :)
People who pay my salary want it :) IIRC Jim Gettys suggested it just
because it'd be easier, not because he didn't actually want dynamic
> A mount option would be in order to disable/enable it I guess.
OK, I'll do that. Makes a lot of sense. It'll be working fine before we
get the GC issues solved.
> The problem with dynamic compression is that we cannot make a failsafe GC
> run, because when joining nodes the resulting node can have a larger
> size and thus we cannot guarantee that the GC run will stop. This can be
> counteracted by allowing the GC to avoid the join in that case, but then
> it's not really a GC and we run into other problems.
We'll still merge nodes in the majority of cases - we'll only have to
refuse to do so in the case where the merge actually expands the node
_and_ we've not got enough slack space to cope, which is going to be very
rare, if it ever happens at all.¹
> You remember that discussion we had some months ago where we discussed how
> to make a failsafe GC run. You mentioned this problem yourself :) Can we
> solve it some way ?
One suggestion is just to write the same (partially obsoleted) data out
again, marking it in some way so that it goes in the right place in the
list chronologically - either writing it out again with the same version
number, or adding an 'original_version' field to the raw node.
¹ Given a compression algorithm, if we could deduce formal
proof that it's never possible for the combined compressed size of two
overlapping nodes to exceed the compressed size of the single combined
node, then we wouldn't have to worry about it. Given that when we combine
two nodes into one, the actual compressed data can expand by the size of
the jffs_raw_node before the combined node actually takes up more space
than the original two nodes, that might not be impossible.
For a trivial RLE compression scheme, that's self-evident. Inserting a
node will break two runs at most, and 80-odd bytes is more than enough to
make up for it. Admittedly, applying the same principles to zlib is going
to be more interesting :)
To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to email@example.com