Changes between Version 30 and Version 31 of Developer/FileSystems


Ignore:
Timestamp:
Nov 22, 2014, 5:33:29 AM (5 years ago)
Author:
Chris Johns
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Developer/FileSystems

    v30 v31  
    1010Embedded applications benefits of using files are:
    1111
    12 # Standardized means of accessing and controlling files.
    13 # Portable applications.
    14 # Support for 3rd party type applications, eg web servers.
    15 # Simplified remote access to networked data.
     121. Standardized means of accessing and controlling files.
     131. Portable applications.
     141. Support for 3rd party type applications, eg web servers.
     151. Simplified remote access to networked data.
    1616
    1717The downside is a larger embedded foot print for code and data, and file system accesses are typically not real-time.
     
    2323RTEMS supports the following file systems:
    2424
    25 # IMFS or In Memory File System
    26 # MiniIMFS Minimal In Memory File System
    27 # JFFS2 or Journalling Flash File System, Version 2
    28 # TFTP or Trivial File Transfer Protocol File System
    29 # FTP or File Transfer Protocol File System
    30 # NFS or Network File System
    31 # FAT or MSDOS File System using the Block Device API.
     251. IMFS or In Memory File System
     261. MiniIMFS Minimal In Memory File System
     271. JFFS2 or Journalling Flash File System, Version 2
     281. TFTP or Trivial File Transfer Protocol File System
     291. FTP or File Transfer Protocol File System
     301. NFS or Network File System
     311. FAT or MSDOS File System using the Block Device API.
    3232
    3333The root file system is always the IMFS file system. It provides a small footprint means to allow device driver nodes to be located in the file system, and to mount other file systems. There is also the MiniIMFS which is smaller in size with less features.
     
    3535RTEMS provides a block device API. Built onto the block device API is a cache. The MSDOS file system uses the cache and therefore the Block Device API. The block devices supported are:
    3636
    37 # ATA disks supporting IDE disk drives as well as Compact Flash disks configured in IDE mode
    38 # RAM disk
    39 # Non-volatile disk
    40 # Flash disk
     371. ATA disks supporting IDE disk drives as well as Compact Flash disks configured in IDE mode
     381. RAM disk
     391. Non-volatile disk
     401. Flash disk
    4141
    4242The specific file system sections provide details of using that file system in RTEMS. The {{{fileio</code> sample application in the {{{testsuite/samples</code> source code of RTEMS provides a good example of the various configurations needed for the various file systems. The {{{fileio</code> example make use of the RTEMS Shell commands. The shell provides a range of commands that can be used to mount, format, copy and delete files on a file system.
     
    5252
    5353
    54 <i>Add details</i>
     54''Add details''
    5555= RFS File System =
    5656
     
    8686The Block Devices interface provides file systems a standard way to access block devices. The block device library consists of the block device API, a cache, and the block driver API.
    8787
    88 <blockquote>
    89 {| border="1" cellpadding="5" cellspacing="0"
    90 |-
    91 ! style="background:#efefef;" | File System
    92 |-
    93 ! align="center" | Block Device Cache
    94 |-
    95 ! align="center" | Block Devices
    96 |-
    97 ! align="center" | Block Device Drivers
    98 |}
    99 </blockquote>
     88
     89||= File System =||
     90|| Block Device Cache ||
     91|| Block Devices ||
     92|| Block Device Drivers ||
     93
    10094
    10195The block devices supported are:
    10296
    103 # ATA Disk Drives
    104 # RAM Disk
    105 # Non-volatile Disk
    106 # Flash Disk
    107 # SPI SD Card
     971. ATA Disk Drives
     981. RAM Disk
     991. Non-volatile Disk
     1001. Flash Disk
     1011. SPI SD Card
    108102
    109103Block devices are normally accessed from the block device cache and not directly. The Block Device drivers are specific to the type of hardware used to access the disk media.
     
    137131The block device cache is a central cache for all block devices. The cache reads blocks into memory and holds them until the space is needed by another block. Modified blocks are held in memory for a period of time before being flushed to disk. The cache configuration data is:
    138132
    139 # Number of different size pools
    140 # Number of blocks in a pool
    141 # Number of read-ahead blocks read
    142 # Number of blocks written when writing
    143 # Swap Out task priority
    144 # Hold time of a buffer
     1331. Number of different size pools
     1341. Number of blocks in a pool
     1351. Number of read-ahead blocks read
     1361. Number of blocks written when writing
     1371. Swap Out task priority
     1381. Hold time of a buffer
    145139
    146140A read of a block will attempt to read the read-ahead number of blocks if the cache has the space. This lowers the number of driver transactions when reading a file and allows multi-sector read drivers to take advantage of the extra performance. The cache will not use other blocks in the cache for a speculative read another block.