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

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
> 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.

You're right, overall it's the same.  But if it takes a very long time
to pull the whole initrd fs and the init was going to make visual
feedback quickly otherwise, we changed the user perception significantly.

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

Wah that is pretty suggestive.

>> 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 :)

Wrong horse is not totally fatal, with Milosch's PBE/initrd type system
we can come up in a way where we didn't touch the NAND and even consider
to reformat it "in place" with the help of a PC.

The problem is once we ship them, if it turns out that the new method
has a bug that craps on the same NAND block over and over all day until
it trashes the chip, or it damages the rootfs so it can't boot after two
months of operation: that would not be good.

> 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.

Wasn't somebody telling me DFU is a burden for end users to suffer
yesterday in another thread?  ;-)

I raised this "what are we shipping firmware-wise" question elsewhere
because it's pretty important we get an answer soon.

>> 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.)

To put a figure on it, right now on 2.6.24 with the lcm console disabled
and 400MHz, it's 32s to mount the rootfs.

If you can approach 50% speedup (which would be awesome), that's 16s,
considering the "improbable target" of 20s for everything including
initscripts  it's still too long when we can chop it to 3 - 4s by the
partitioning action IMO.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHiJEDOjLpvpq7dMoRAis1AJ9XhfBtFlxnqHg3k+ZdkwhY5rrivQCeIg+S
1zCT+FjL397Fi9LhAG8pQ0s=
=PxiV
-----END PGP SIGNATURE-----