1. Benefiting government, industry and the public through innovative science and technology A Simple Flash File System For Embedded Space Applications October 28, 2015 John Harwell jharwell@swri.org (210)-522-5965 10/28/151

2. Outline  Motivation And Purpose  File Systems Background  Target Environments  Interstellar File System (IFS) Overview  Next Steps 10/28/152

3. Motivation And Purpose  Many existing Flash file systems for FSW applications – Limited wear leveling – Do not intrinsically utilize supplemental non-volatile storage for file system metadata – Configurability  In-progress report of independent research to address these issues 10/28/153

4. Flash File System Hierarchy 10/28/154

5. File Systems on Flash Media 10/28/155  Concern: limited write/erase cycles (10x deration) – Different write paradigm than magnetic media – Different superblock paradigm than magnetic media

6. An Example File System Transaction 10/28/156  Writing two files in two directories Written every transaction!

7. Target Environments Overview  FSW OSes – RTEMS – VxWorks – Others  Integration via Virtual File System (VFS) layer – POSIX compliance  Stand alone 10/28/157

8. Flash File Systems in RTEMS  JFFS2 port – Boot time scales with device size – Documentation suggests it does not provide ideal wear leveling  RFS (RTEMS File System) – Supports Flash via the Flash disk driver, but no built-in wear leveling  FAT – No wear leveling 10/28/158

9. Flash File Systems in VxWorks  Licensing requirements  HRFS – High fault tolerance – Difficult to find description of features  TrueFFS – Magnetic disk emulation (no wear leveling)  RT-11 (deprecated) – Primitive interface/features, high performance (no wear leveling) 10/28/159

10. Interstellar File System (IFS) Overview 10/28/1510

11. IFS Configurability  “As simple as possible, but no simpler”  Dual APIs: – Direct access to IFS core – Access via VFS interface (in progress)  Exposes fine-grained configuration options – Maximum programmer flexibility – Maximum mission adaptability 10/28/1511

12. IFS Storage Awareness  Non-volatile storage awareness/utilization – MRAM, EEPROM, etc – Fast boot times – Increased reliability – Significantly increased Flash utilization/lifetime 10/28/1512 Written every transaction!

13. IFS Integrity  Error/event reporting – Standard POSIX error codes – Configurable event logging (errors and normal operations) for later telemetry downlink  Stateless – Atomic transaction model (no buffered writes or FILE* handles) – Certain configurations do not require fsck() at all  No dynamic memory allocation 10/28/1513

14. IFS Segment Compaction  Page per write unit – 4KB vs 128KB page for 1 byte write  Improves Flash utilization significantly  fsck() required if device driver does not support page read-modify-write  Reduces wear-leveling to approximate 10/28/1514

15. IFS Garbage Collection  Configurable cleanliness threshold  Configurable, bounded execution time  Can be automatic or application driven 10/28/1515

16. Next Steps  Finish POSIX compliance in the IFS core  Finish VFS layer bindings for RTEMS  Core improvements 10/28/1516

17. Summary  Several Flash file systems available for RTEMS, VxWorks, and others – Wear leveling offerings appear to be lacking – Are not MRAM/EEPROM aware (reliability, boot time concerns) – Limited configurability (sometimes not desirable)  IFS – “As simple as possible but not simpler” – MRAM/EEPROM aware – Configurable to provide ideal wear leveling, and/or eliminate the need for fsck() – Configurable garbage collection, segment compaction 10/28/1517

18. Benefiting government, industry and the public through innovative science and technology A Simple Flash File System For Embedded Space Applications October 28, 2015 John Harwell jharwell@swri.org (210)-522-5965 10/28/1518