mount time (was Re: Fwd: Hello -- NAND/NOR Flash design for GTA02)
werner at openmoko.org
Fri Jan 11 18:23:09 CET 2008
[ Cc:s trimmed ]
Andy Green wrote:
> This will need unpacking / regenerating when packages want to stick
> things in there,
Yep, fast but ugly.
>> - overlay (Joachim, OpenWRT uses squashfs+jffs2)
> Didn't find anything on Joachim in Google.
I meant "our" Joachim, "roh". He pointed out that OpenWRT has this
squashfs+jffs2 solution that also includes an overlay mechanism.
>> - as a variation of the above, separate read-only data from read-write
>> data - only the latter needs scanning (that's from OpenWRT again)
> Hey that's pretty good, having a ro /usr is not so uncommon, we can
> mount -oremount,rw when we do a package change.
Not so quick :-) If it isn't strictly read-only, it still needs a
structure that supports scanning.
> I guess we would take a gamble if we chose LogFS, there is limited time
> to gain experience with it but I guess it can be possible.
Yep, still needs more investigation. Another candidate would be
UBIFS, which is even newer, but considerable development seems to
have happened before it was announced:
> Hey what happens if you mounted the root filesystem ro, did the whole
> initscripts without a writable /? Would it come up immediately and then
> you can start mounting rw at a mountpoint,
The problem is that, in order to find all the files stored in the
file system, jffs2 has to scan the entire Flash:
So, if I understand the logic correctly, a partial scan gives you the
- inode X encountered, deleted flag not set -> inode X exists
- inode X does not exist -> inode X not encountered OR
inode X encountered, deleted flag set
This isn't a consequence of being able to write at that moment, but
it's a consequence of that file system supporting writes at all.
More information about the openmoko-kernel