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:
> [ Cc:s trimmed ]
> 
> Andy Green wrote:
>> This will need unpacking / regenerating when packages want to stick
>> things in there,
> 
> Yep, fast but ugly.

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.  We could also accept that we keep also an
unpacked tree of it in /, then we only have to compress that on changes.

It'll have to go in its own partition, making choosing the size of that
part pretty tough since it will be a hard fatal limit on what we can
include in the early boot action.

> I meant "our" Joachim, "roh". He pointed out that OpenWRT has this
> squashfs+jffs2 solution that also includes an overlay mechanism.

Gah!

>> 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:
> http://www.linux-mtd.infradead.org/doc/ubifs.html

We can't decide on any new FS without experiencing it, that is for sure.
 Maybe we should aim to pick one or two from { yaffs, ubifs, logfs } and
one or more of us DFU a rootfs in that format on a device (assuming they
allow such things as offline filesystem generation), see what happens.

Obviously the downside of making a choice with hidden flaws (or, well,
more hidden flaws than JFFS2) could be extreme, but we have to balance
that risk against the current JFFS2 mount time which is everyone can
agree is an unacceptable source of suckage That Must Change.

It seems it is tough to argue against the proposition that JFFS2 is in
fact the "safer" option at the moment compared to the untested
filesystems.  Maybe if we can demonstrate capability through stress like

http://www.coker.com.au/bonnie++/

in one of the other filesystems we can gain enough confidence to sell
people devices that rely on it.  But I think it puts us in a hard
position to convince others of that when we only have a few weeks to
gain trust in it ourselves and none of the other options (except the
initrd one) are claiming to be mature.

> The problem is that, in order to find all the files stored in the
> file system, jffs2 has to scan the entire Flash:
> http://sources.redhat.com/jffs2/jffs2-slides-transformed.pdf

Understood: no free lunch at the JFFS2 canteen.

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

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

 - reduce the footprint you scan

 - increase the scan rate radically (80% improvement does not seem
credible in hard NAND bandwidth?)

 - change the scanning game with a new fs type and make a plan to
mitigate the risk (low risk if initrd though)

- -Andy

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

iD8DBQFHh7TvOjLpvpq7dMoRAg8tAJ9r4cT+x0aoaWI1IxAOzbv2iLB7ngCffI4M
JLgPloudQ9OAzFNyqQEYXEo=
=UKBU
-----END PGP SIGNATURE-----