wiki:Developer/FileSystems

Version 20 (modified by Strauman, on 02/08/09 at 06:47:19) (diff)

File Systems

RTEMS provides support for file systems. The POSIX standard and the Single Unix Specification define a range of calls that allow applications to access and control files on a file system. Embedded systems have evolved to allow support for file systems and files. Files are a well understood means of managing various forms of data on desktop and server type system and the same can also apply to embedded system with some obvious constraints.

Embedded applications benefits of using files are:

# Standardized means of accessing and controlling files. # Portable applications. # Support for 3rd party type applications, eg web servers. # Simplified remote access to networked data.

The downside is a larger embedded foot print for code and data, and file system accesses are typically not real-time.

The code and data size depends on the file system being used. A simple TFTP type file system has a small foot print but does require a networking stack. A block device file system such as the FAT file system has the overhead of implementing a full file system plus the cache.

Real-time use of a file system is a complex issue and beyond the scope of this topic. Dr Joel Sherrill's PHD thesis studied real-time file-systems and concluded the whole system from application to driver needs to be considered when handling real-time data. You should contract Joel if you would like advise on this topic. Typically an application would read configuration type data into memory rather than use the file-system directly.

RTEMS supports the following file systems:

# IMFS or In Memory File System # MiniIMFS Minimal In Memory File System # TFTP or Trivial File Transfer Protocol File System # FTP or File Transfer Protocol File System # NFS or Network File System # FAT or MSDOS File System using the Block Device API.

The 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.

RTEMS 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:

# ATA disks supporting IDE disk drives as well as Compact Flash disks configured in IDE mode # RAM disk # Non-volatile disk # Flash disk

The 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.

IMFS File System

The In Memory File Systems is always the root file system and uses the standard C library heap for storage. The file system will only consume memory for the nodes and files it holds and releases memory back to the heap when no longer used. The design of this file systems is full standards support, small foot print and lower memory overhead. The file system is also fast for small sized files and directories. This suits small configuration files and device driver nodes.

This file system is volatile. After an application restart you will need to construct its contents. RTEMS provides some supporting calls for this plus there is the ability to tar files into it.

The file system is ideally suited to holding files typically found in <tt>/etc</tt> or <tt>/dev</tt> on a Unix system. The RTEMS networking stack has been taken from FreeBSD and supports files such as <tt>/etc/hosts</tt> and <tt>/etc/resolv.conf</tt>. It is better to provide application support for DNS resolution via <tt>/etc/resolv.conf</tt> than the proprietary RTEMS calls added to the networking code. RTEMS supports the standard Unix type driver interface. You can register a driver with RTEMS and place a node in the file system that maps to that driver. The Unix standard major and minor device numbers are supported. Device nodes provide a standard means of access to a device. For example, a specific target BSP may provide a termios serial (UART) driver node called <tt>/dev/cfuart0</tt> which is named after the hardware yet an application may like a more logical name such as <tt>/dev/ttyS0</tt>. A simple solution is to create a symbolic link from <tt>/dev/cfuart0</tt> to <tt>/dev/ttyS0</tt>. The application is now isolated from hardware specifics via the file system.

MiniIMFS File System

<i>Add details</i>

TFTP File System

The TFTP File System provides simplified file access and no file control type operations. The file system allows access to read and write files from a remote TFTP server. You can open and read a file or open and write a file. You cannot seek on the file or perform file control operations such as delete the file or list a directory. The file system is useful when a more complete networked file system such as NFS is not needed and you wish to copy files to the target or to read a configuration.

The TFTP client does not support the various TFTP options such as block size so the performance of this file system is slow due to the default 512 byte packet size used.

The file system addresses hosts by parsing the file's path under the mount point. For example if the TFTP file system is mounted under the default mount point of <tt>/TFTP/</tt> an open of a file <tt>/TFTP/10.10.10.1/readme.txt</tt> would attempt to read using the TFTP protocol the file <tt>readme.txt</tt> from the host <tt>10.10.10.1</tt>. The file name used in the TFTP read request would have the leading <tt>/</tt> removed.

FTP File System

<i>Add details</i>

NFS File System

RTEMS supports the NFS or Network File System. This is a full featured file system that provides the full range of file access and file control functions. The NFS code is currently outside the <tt>cpukit</tt> and it is hoped it will move into the <tt>cpukit</tt> in a future release (update: with the RTEMS-4.9 release NFS became part of the <tt>cpukit</tt>).

MSDOS File System

RTEMS supports the MSDOS file system or the FAT (File Allocation Table) File System. This file system uses the block device library and the block device drivers to access various types of disk media.

<blockquote> {| border="1" cellpadding="5" cellspacing="0"

! style="background:#efefef;" | MSDOS File System

! align="center" | Block Device Cache

! align="center" | Block Devices

! align="center" | Block Device Drivers |} </blockquote>

The file system interfaces to the cache. The cache provides a performance increase to applications using the MSDOS file system. Many FAT operations require more than one pass over a FAT directory or the FAT table and holding this data in memory increases performance. The Block Devices layer is optional and provides any specific device protocols, for example ATA disks. Any file system could use the Block Devices layer how-ever only the MSDOS file system does. The block devices supported are:

# ATA Disk Drives # RAM Disk # Non-volatile Disk # Flash Disk # SPI SD Card

Block devices are normally accessed from the block device cache and not directly. The Block Device driver are specific to the type of hardware used to access the disk media.

See Using the RTEMS DOS File System to see how to configure and use this file system in RTEMS.

The MSDOS file is tested against FreeDOS and Windows.

ATA Disk Drives

The ATA Disk Drive supports IDE type disk media. The device normally has a Master Boot Record and a partition table. The ATA Disk driver is currently located in libchip and the disk can be a hard disk or a Compact Flash disk in IDE mode.

The ATA driver is a task that interfaces to a BSP supplied driver. The BSP initializes a table with the BSP driver functions. Initialization and mounting of a partition on an ATA disk is a 2 stage process. The Master Boot Record (MRB) is read from the disk and valid MSDOS partitions added as devices. The mounting of a partition requires a partition device path and a mount point.

RAM Disk

The RAM disk allows a fixed sized disk to exist in RAM. You can provide the address of the RAM or let the driver allocate the RAM from the heap. If you create a disk from the heap you will need to format it. Providing the RAM address allows you to use static RAM that could survive a reset and may or may not need to be formatted during initialisation. If the RAM is battery backed up you may consider the Non-volatile or NVDISK driver. The RAM disk does not provide any checking on the blocks in RAM. It is the fastest block device driver.

Non-Volatile Disk

The Non-volatile or NVDISK is similar to the RAM disk how-ever each block has a checksum. It provides a one to one mapping of blocks to the memory like the RAM disk but it also adds a CRC checksum on each block. The NVDISK driver is suitable for battery backed up static RAM or EEPROM type devices that are byte re-programmable.

Flash Disk

The Flash disk driver or FDISK driver maps a block disk device to flash devices. You can specify the devices and how much of each device to use when creating a disk. This allows the disk to share a boot image. The driver will manage the flash sectors/segments and handle the mapping of the disk blocks to the flash devices. The types of flash supported is independent of the flash driver. You define device descriptions the flash driver uses. The flash driver is not a flash file system, rather it is a way to map an existing block device file system to flash devices. Currently the flash driver does not support NOR flash devices and does not journal blocks written to the disk. This means you need to manage power failures. Journaling support could be added in the future and if you are interested in supporting this please contact OAR Corp.

The flash driver does manage the moving of blocks to allow the the recovery of flash segments (sectors). The compaction operation can cause flash updates to vary in length.

SPI SD Card

The SPI SD Card driver is locate in libchip. It uses libi2c and despite this libraries name supports I2C and SPI serial bus interfaces.

Block Device Cache

The 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:

# Number of different size pools # Number of blocks in a pool # Number of read-ahead blocks read # Number of blocks written when writing # Swap Out task priority # Hold time of a buffer

A 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.

The cache has a swap out task that collects blocks who's hold timer has expired for a specific device and writes them to disk device. Each modified block as an individual timer and the cache can be configured by the driver to only write consecutive blocks helping drivers that support the multi-sector write operations.

The cache can be synchronized at the request of a user giving an application full control over the data written to the disk media. If you do not synchronize the data with the disk media before your applications terminates data could be lost or the file system could become corrupted. To synchronize the cache for a specific disk use the following code:

int fd = open (driver, O_WRONLY, 0); if (fd < 0) {

fprintf( stderr, "%s: driver open failed: %s\n", argv[0], strerror (errno)); return 1;

}

if (ioctl (fd, RTEMS_BLKIO_SYNCDEV) < 0) {

fprintf( stderr, "%s: driver sync failed: %s\n", argv[0], strerror (errno)); return 1;

}

close (fd); return 0;

Device Only File System

The device-only filesystem is a light-weight filesystem only for device. It uses kernel workspace for storage. The memory consumption is a constant and can be changed during user application configuration time. The device-only filesystem is designed only for devices nodes.