= File Systems = {| border="0" cellpadding="5" cellspacing="0" align="right" |- ! style="background:#efefef;" | |} 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 sample application in the {{{testsuite/samples source code of RTEMS provides a good example of the various configurations needed for the various file systems. The {{{fileio 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 suites hold 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 file typically found in /etc or /dev on a Unix system. The RTEMS networking stack has been taken from FreeBSD and supports file such as /etc/hosts and /etc/resolv.conf. It is better to provide application support for DNS resolution via /etc/resolv.conf 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 a device. For example a specific target BSP may provide a termios serial (UART) driver node called /dev/cfuart0 which is named after the hardware yet an application may like a more logical name such as /dev/ttyS0. A simple solution is to create a symbolic link from /dev/cfuart0 to /dev/ttyS0. The application is now isolated from hardware specifics via the file system. = MiniIMFS File System = Add details = 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 /TFTP/ an open of a file /TFTP/10.10.10.1/readme.txt would attempt to read using the TFTP protocol the file readme.txt from the host 10.10.10.1. The file name used in the TFTP read request would have the leading / removed. = FTP File System = Add details = 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 cpukit and it is hoped it will move into the cpukit in a future release. = 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 implement the file system.
{| 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 |}
The Block Devices layer provides a buffering and caching type function that improves the performance of the file system. It also provides a simplified driver interface. 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 Block devices are normally accessed using the block device cache. See [wiki:TBR/UserManual/Using_the_RTEMS_DOS_File_System Using the RTEMS DOS File System] to see how to configure and use this file system in RTEMS. = ATA Disk Drives = The ATA Disk Drive support allows an IDE type device to be accessed. The device normally has a Master Boot Record and a partition table. The ATA Disk driver is currently located in libchip. The IDE 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 loaded into a table. 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 various partition checks. The mounting of a partition requires the selection of a partition and a mount point. = RAM Disk = The RAM disk allows a fixed sized disk driver to be created 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. If you provide the address of the RAM to use it could reside in static RAM and therefore survive a reset and may or may not need to formatted. 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 file system. = Non-Volatile Disk = The Non-volatile or NVDISK is similar to the RAM disk who-ever each block has a checksum. It provides a one to one mapping of blocks to the device like the RAM disk but it also adds a CRC checksum on each block. The NVDISK drive 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. 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. = 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.