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