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

Re: JFFS compression and hard links.

bjorn.wesen@xxxxxxx.com said:
>  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.

Hmmm... yeah, that could possibly work. It'll make the node lists more 
complex, so as we've already got to break compatibility I'm tempted just to 
add the extra field.

bjorn.wesen@xxxxxxx.com said:
> 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.

S'cheating. :)

We might as well bite the bullet and do dynamic compression right from the
start - people want it.

bjorn.wesen@xxxxxxx.com said:
>  Heh I don't even know hard-links semantics in normal filesystems so
> I'll let that pass :)  

Simple - the same inode is linked to by two or more directories. 

Doing that in JFFS is going to be, erm, interesting. It basically means 
you can't have 'name' or 'parent' information in the inode itself - you 
have to have directory structure represented another way.


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