[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: JFFS compression and hard links.
From: David Woodhouse <email@example.com>
To: Bjorn Wesen <firstname.lastname@example.org>
Date: Tuesday, January 09, 2001 18:32
Subject: Re: JFFS compression and hard links.
>> 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.
Wouldn't it be possible to add a "compressed bit" in reserved field and
then say that the first 32 bit number of the data is the length?
(And then come the compressed data)
This would mean that the flash structure doesn't really change and is
backword compatible (if we really care), but the internal representation
has the extra field.
Mayby to kludgy, I don't know....
To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to email@example.com