Lantronix EDS2100 Linux SDK - User Guide - Page 27

Supported File Systems, Introduction, ROMFS

Page 27 highlights

4. Supported File Systems Introduction Linux supports a wide range of file systems. Most of them were created with certain characteristics in mind: high performance, reliability, compatibility with other operating systems, general purpose, etc. Raw flash devices have inherently different characteristics than block devices such as hard drives and USB flash drives:  Flash areas have to get explicitly erased before they can be overwritten  Erase blocks, the smallest entities that can be erased on a flash, are usually considerably larger then sectors on hard drives  Limited number of rewrites (memory wear) To address these constraints numerous file systems for raw flash devices exist. Among the most popular are:  ROMFS  JFFS2  CRAMFS  SQUASHFS ROMFS and JFFS2 are supported in this SDK and described in detail below. Both CRAMFS and SQUASHFS are read-only file systems that support compression. They are not currently supported in this SDK since they are not part of the standard Linux kernel as of version 2.6.30. It should be relatively straightforward for the adventurous to add support for them. The home page of the maintainers of JFFS2 (www.linux-mtd.infradead.org) provides excellent information about raw flash devices. ROMFS What Does ROMFS Offer ROMFS is the default file system for the µClinux distribution. It is a read-only uncompressed file system with minimal overhead. The boot loader copies or decompresses the Linux kernel and the ROMFS into RAM (if romfs_flash is disabled) before jumping into the kernel. This has a few implications:  Since the root file system and the kernel are in RAM they can be easily overwritten on the fly by the firmware update process (unless ROMFS is executed from flash fr).  Only applications that need to run all the time should be kept in ROMFS because everything consumes valuable RAM space.  This may compensate easily for the waste of RAM if multiple instances of an application run at the same time. Linux Software Developers Kit (SDK) User Guide 27

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76

Linux Software Developers Kit (SDK) User Guide
27
4. Supported File Systems
Introduction
Linux supports a wide range of file systems. Most of them were created with certain
characteristics in mind: high performance, reliability, compatibility with other operating systems,
general purpose, etc.
Raw flash devices have inherently different characteristics than block devices such as hard drives
and USB flash drives:
Flash areas have to get explicitly erased before they can be overwritten
Erase blocks, the smallest entities that can be erased on a flash, are usually considerably
larger then sectors on hard drives
Limited number of rewrites (memory wear)
To address these constraints numerous file systems for raw flash devices exist. Among the most
popular are:
ROMFS
JFFS2
CRAMFS
SQUASHFS
ROMFS and JFFS2 are supported in this SDK and described in detail below. Both CRAMFS and
SQUASHFS are read-only file systems that support compression. They are not currently
supported in this SDK since they are not part of the standard Linux kernel as of version 2.6.30. It
should be relatively straightforward for the adventurous to add support for them.
The home page of the maintainers of JFFS2 (
www.linux-mtd.infradead.org
) provides excellent
information about raw flash devices.
ROMFS
What Does ROMFS Offer
ROMFS is the default file system for the µClinux distribution. It is a read-only uncompressed file
system with minimal overhead.
The boot loader copies or decompresses the Linux kernel and the ROMFS into RAM (if
romfs_flash is disabled) before jumping into the kernel. This has a few implications:
Since the root file system and the kernel are in RAM they can be easily overwritten on the fly
by the firmware update process (unless ROMFS is executed from flash fr).
Only applications that need to run all the time should be kept in ROMFS because everything
consumes valuable RAM space.
This may compensate easily for the waste of RAM if multiple instances of an application run
at the same time.