[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: JFFS compression and hard links.
On Tue, 9 Jan 2001, David Woodhouse wrote:
> I'm now working on JFFS compression, for which I'm starting on dealing with
> erase blocks individually, as discussed here many moons ago.
> This is going to break compatibility with older filesystems which have
> nodes overlapping from one erase block to another.
We can live with that..
> Compression also needs to break compatibility, because I think we need to
> store _both_ the compressed and the uncompressed size of the data attached
> to each node.
We definately need the compressed footprint. It's not obvious that the
uncompressed size needs to be there - each jffs node on flash will be a
separate contigous compressed block but with an "uncompressed" data
offset. So if we need to find bytes 20000-21000 of a file, we'd find the
node with data offset closest under 20000, unpack it and hope all the data
is there otherwise look for the next node and unpack that as well.
This gets much simplier if we make the decision to only support
compress-once systems, where mkfs.jffs will do the compression and do it
so each jffs_node corresponds to one page, a la cramfs. That makes
readpage trivial, in the same way as cramfs readpage is. You just find the
node corresponding to the page by using the data offsets, then unpack it
into the page cache.
Now if we really want to support compressed runtime JFFS writes (without
say a specific user-mode tool to compress a single file) things get much
more hairy, I remember writing the reason why this is a road to hell
sometime but I don't remember why exactly. Then you'd definately need the
uncompressed size to actually be able to figure out which part of a file
to read, if some parts are compressed and some not...
I think the compress-once would be a good beginning, and I guess including
the uncompressed size for good measure (and being able to handle
compressed writes on the fly later) would be useful..
> While we're at it, we might as well come up with a scheme for implementing
> hard links. We don't have to actually _implement_ it, just decide whether
> it's going to need another compatibility-breaking change in the on-media
> format, and build that in right now if it is.
Heh I don't even know hard-links semantics in normal filesystems so
I'll let that pass :)
To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to email@example.com