Feature roadmap/Replace JFFS file system with better one
Jump to navigation
Jump to search
Feature subcategory | Is part of::Category:Linux and OS | |
Requesters | {{#arraymap:User:Deepak|,|x|Requested by::x}} | |
Requirements | * End users will see faster boot up time and will not see (as much) performance degradation as the file system fills up. Paging from the file system will not burn huge amounts of CPU time. | |
Specification | The current file system used on the XO ([JFFS2]) was developed in the days of 32/64MiB NOR flash devices and does not scale well to the 1GiB NAND devices we are using today and certainly will not deal well with larger devices in gen 1.5 and gen 2 systems. The main issues are that JFFS2 needs to scan all blocks at mount time and that the garbage collection algorithm increasingly consumes CPU cycles as the system fills up. The first issue manifests itself as large delays at boot up to mount the file system as it is full (need to quantify this), and the second issue simply means less CPU cycles can be dedicated to user task processing. Paging executables in from JFFFS seems to result in large CPU time usage as memory becomes scarce: read-only code pages are thrown out (because they're the only pages that can be discarded on demand) and re-read numerous times; the system seems to become much more sluggish than an ext3 disk-based Linux system.
In the last few years, there has been much activity in the embedded Linux world on alternatives to JFFS2 and we need to investigate these to determine which one best fits our needs:
Development process
Deployment process
Activity impact End-user impact | |
Owners | {{#arraymap:Deepak|,|x|Contact person::User:x}} | |
Priority | not indicated | |
Helps deployability? | not indicated | |
Target for 9.1? | not indicated |