mount time (was Re: Fwd: Hello -- NAND/NOR Flash design for GTA02)

Werner Almesberger werner at openmoko.org
Fri Jan 11 19:51:22 CET 2008


Andy Green wrote:
> It's not out of the question if the amount of stuff you need in there to
> take up a meaningful percentage of the init time does not require a long
> dead time to pull from NAND.

Yup. In fact, if this contains only files we have to read anyway
(which would be the idea situation we should try to approach),
there's no penalty.

> We could also accept that we keep also an
> unpacked tree of it in /, then we only have to compress that on changes.

That's an interesting idea as well.

> We can't decide on any new FS without experiencing it, that is for sure.

Yeah. I think I've found all the contenders by now. The code of both
LogFS and UBIFS looks clean to me (more consistent with kernel coding
style than YAFFS2). UBIFS seems to be DFU-compatible. Not sure about
LogFS yet.

LogFS is pretty small, with only ~7600 lines, while UBIFS has more than
28'000, plus more than 11'000 for its UBI layer.

> Obviously the downside of making a choice with hidden flaws (or, well,
> more hidden flaws than JFFS2) could be extreme,

Indeed. Short-term (FS corruption) as well as long-term (betting on
the wrong horse). But it seems that we can only choose among
different evils :)

By the way, I'm not sure if we have a firm plan to actually put a
usable rootfs on the first batch of GTA02 devices. If we follow the
GTA01 route ("before you start, please DFU"), this would give us
(and others) considerably more time to find and kill any bugs.

> It does indeed sound like the only way to win on that game is to

Yup. As usual, the greatest improvements (1-2 orders of magnitude)
would come from fixing the algorithm. Splitting partitions might
get us something like a factor of 10. Just making things faster
probably less than 50%. (Wild guess alert. I have to do some real
benchmarks forthis.)

- Werner




More information about the openmoko-kernel mailing list