User:Erik Garrison/Partitioning: Difference between revisions
Jump to navigation
Jump to search
(created sub-page for partitioning work) |
|||
Line 1: | Line 1: | ||
= XO partitioning.= |
= XO partitioning.= |
||
Code for building a partitioned image out of a set of file trees: [http://dev.laptop.org/git?p=users/erik/olpc-image-tools;a=summary]. Ready to implement, waiting on myself and discussions about 9.1 requirements. |
|||
''Objective'': Implement partitioning to enable the following features: |
''Objective'': Implement partitioning to enable the following features: |
Latest revision as of 20:58, 30 September 2008
XO partitioning.
Code for building a partitioned image out of a set of file trees: [1]. Ready to implement, waiting on myself and discussions about 9.1 requirements.
Objective: Implement partitioning to enable the following features:
- Improved OFW-level flash updates. Partitioning can isolate user files from system ones and provide a method to isolate flash updates of the system.
- LZO compression of system and user files. LZO compression can yield large (~500%) disk read/write performance gains over zlib (currently used). The existing single-partition layout would require the introduction of LZO support into OFW. While this might be a useful project, we need not seek to implement every compression format available in the Linux kernel in OFW. Partitioning will allow us to keep the boot partition in a format which OFW can decompress (probably zlib), but move system and user files to LZO to realize performance gains during post-early-boot system operation.
- Boot failure due to NAND fillup. In-field observation suggests that the dangerous situation in which NAND is completely filled arises mostly because users download activities and large media files to their home directories (datastore). Provided system boot can complete without writing to user- controlled partitions (which must be verified), partitioning offers a pattern to protect the system from the effects of such user activity. On its own it won't resolve the less-common problem of system NAND fillup.
Major issues:
- Update of systems from single partition to multiple. The change of partition structure means that system updates will likely have to move user data off the memory device and onto an external storage unit, repartition the NAND, and copy user data back into the new user data partition after the system NAND update is complete. This is a non-trivial support problem. If possible it is strongly desirable to provide a method to update a running system. Doing so will likely require sufficient space to shuffle user data around during update, and it may be that there is no specific solution.
- Assembly of partitioned images. See: AddJFFS2SupportUsingATrailerPartitionTable. There is an existing tool (slugimage) which can be used to produce partitions readable by the code in the Linux source tree (drivers/mtd/redboot.c). Assembly should ideally be introduced into the build process.