Feature roadmap/Replace JFFS file system with better one: Difference between revisions
Jump to navigation
Jump to search
m (fix link to User:Deepak) |
(Add paging CPU time issue) |
||
Line 4: | Line 4: | ||
|Requesters=User:Deepak |
|Requesters=User:Deepak |
||
|Requirements= |
|Requirements= |
||
* End users will see faster boot up time and will not see (as much) performance degradation as the file system fills up. |
* 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= |
|Specification= |
||
The current file system used on the XO ([[http://en.wikipedia.org/wiki/JFFS2 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. |
The current file system used on the XO ([[http://en.wikipedia.org/wiki/JFFS2 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: |
|||
* [http://www.yaffs.net/ YAFFS2] : Has been around for several years and in active use in the embedded space. It does not provide compression out of the box as the devices that use it often carry already compressed data such as MP3 and MPG files. |
* [http://www.yaffs.net/ YAFFS2] : Has been around for several years and in active use in the embedded space. It does not provide compression out of the box as the devices that use it often carry already compressed data such as MP3 and MPG files. |
||
Line 38: | Line 40: | ||
'''End-user impact''' <br> |
'''End-user impact''' <br> |
||
End users will see faster boot up time and will not see (as much) performance degradation as the file system |
End users will see faster boot up time and will not see (as much) performance degradation as the file system and/or RAM fill up. |
||
|Owners=Deepak |
|Owners=Deepak |
Latest revision as of 16:11, 15 January 2009
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 |