[ 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: http://www.linux-mtd.infradead.org/doc/ubifs.html > 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: http://sources.redhat.com/jffs2/jffs2-slides-transformed.pdf So, if I understand the logic correctly, a partial scan gives you the following information: - 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. - Werner
