A comparison of the file systems used in RTLinux and Windows CE Authors : Thomas Österholm, thoos207@student.liu.se Thomas Sundmark, thosu588@student.liu.se This report contains a comparison between some of the different file systems available for RTLinux and Windows CE, and is intended for people with relatively good technical background who wish to broaden their knowledge on the subject. The main conclusion made in the report is that Windows CE is superior when it comes to file systems due to the fact that there exists file systems which have been specifically designed for use in this RT- OS, whereas RTLinux only has access to file systems made for non- RT operating systems.
Introduction The writing of this report is part of a course designed to give an insight into how both non- real time and realtime operating systems work. The topic at hand was chosen due to it seeming like an interesting thing to look into as there isn't an awful lot of information out there on the subject, most likely because the structure of the file system isn't one of the most vital parts of a realtime- OS. Real- time operating system are a type of operating systems created to run on small computer systems and embedded systems requiring very little memory. Devices running a RTOS do not always use storage media, so most RTOS are made to be able to run without a file system. However, a lot of RTOS, such as Windows CE and RTLinux, still have some kind of support for using file systems. The body of the report report is structured so that first a brief overview of the Windows CE RT- OS is given followed by a presentation of some of its available file systems (with focus on File Allocation Table, FAT), and then the same is done for RTLinux (this time with focus on the Extended File system, EXT). After the description of RTLinux follows a short summary of the contents. After the summarization of the body follows a short section of conclusions.
Windows CE Windows CE is an hard real- time operating system created by Microsoft to run on small computer systems and embedded systems, using very little memory. Devices running Windows CE do not always use storage media, so Windows CE is made to be able to run without a file system. However, Windows CE supports a few types of file systems, some controlled by FSD (file system drivers) and some loaded as registered file systems. The idea of a real- time system is to have low interrupt latencies, to meet deadlines and in this case, run on small computers without a lot of memory. Because of this, the operating system has to have a file system which has low interrupt latencies and can be used on small sized storage media. The new and not yet very spread Windows CE 6 is a system made for another market than the earlier versions; it can run 32 768 processes at once instead of 32 (WinCE 5). Windows CE is used in the following applications (among others): Hand- held PCs Mobile Phones Industrial robots This report covers the general idea of Windows CE 5 and earlier versions since the idea of this report is to compare different file systems for small efficient systems. The file systems below are the most commonly used ones for Windows CE, but there are many different versions of these, especially FAT, which contains different features depending on what type of computer will run it. RAM file system (Object Store) Object Store is a RAM (random access memory) based file system and is the default file system for Windows CE. The RAM is divided into program memory and storage. In the storage area, Windows CE temporary stores data or executables in a files and folders type of system. For permanent storage, this file system can be combined with the ROM (read only memory) file system, which makes it possible to save the whole object store on a PROM (programable ROM) when needed. It is possible to retrieve information from the file system and view the files and directories. Object Store include three different types of data sections; the file system, a database and system registry. The files in the file system are always compressed and need to be decompressed before executed. The database stores data in a structured and efficient way. The big database can consist of many different databases and is able to inform running programs when data has been changed. The system registry stores system and program configuration data. Files are limited in size to 32 MB and the total RAM size is limited to 256 MB.
ROM file system One can choose to not use object store, and only use ROM based file system. The ROM file system is good for small applications where the only data needed to save is configuration and perhaps some small files. This system is also able to use other external file systems written on ROM. The external file system can be put in a directory under the root directory of the external storage device. If so, all the data under the used file system is set to belong to that file system and can be recovered through the external file system. CDFS and UDFS The CDFS (compact disc file system) and UDFS (universal disc file system) are used to read data from CDs and DVDs. These systems are made to fit an international standard for CDs and DVDs and will be similar to the ones used for RTLinux, therefore it is not interesting to get into details about them. BinFS Binary Rom Image File System is a file system used with ROM file system and is a way of storing data in binary image files (.bin). The binary image file keeps information specially organized so that a program in execution can load the memory with some information for execution, and in an efficient way get more/the rest of the information when needed. FAT file system FAT (file allocation table) was created by Bill Gates in 1977 and is one of the most commonly used file system type on personal computers, and is supported by almost all operating systems. FAT works with most external storage devices you could plug in to a computer and is still quite simple. This means by using this file system, Windows CE can share files with most other operating systems. There are three versions of the FAT file system; FAT12, FAT16 and FAT32. The number refers to the number of bits in the cluster addresses and the main difference between them are limitations. There are also a number of different file system based on the FAT series, with slight changes, but they will not be covered here. The FAT file system contains four parts, the boot sector, the file allocation table, the root directory and the data section. In the top of the file storage there is a boot sector. When accessing the file system, the boot sector would be the first place to come to. Here the file system can get information about the partition and get redirected to the file allocation table.
The file allocation table (giving the file system its name) is a table where one can find information about clusters, such as which clusters are free, which are used, which are damaged, the address to the next part of a file or if it is the last cluster in the file. There are also pointers pointing to used clusters where data is held. A cluster is somewhere between 2 KB and 32 KB depending on the file system. One file uses one or more clusters, so space left in a cluster after a file used some of it is not possible to use for other files. However, this is not a big issue since in total, not much space is wasted this way. When Windows CE is used with a small amount of memory, the cluster size is normally adapted to that, using only 2 KB per cluster. A file bigger than one cluster is made by linking clusters. This does not mean the clusters are in order, they are often fragmented all over the data space in a cluster chain (fragments of data here and there). The root directory is the first directory on a partition. In FAT12 and FAT16 the root directory had a special place in the file system, right before the data part, which means the size of the root directory and its files is static and cannot be changed once the file system has been created. In FAT32 the root directory is a part of the data section, which means it is as dynamic as any other folder and can contain just about anything. A folder is a data type which keep track on which files are in the folder, and also links to folders within the folder. The folder data type stores information of the files such as when the file was created, last modified, file size, if it is hidden etc. The data section is the biggest part of the file system and it is where the actual data is stored. When storing files, the FAT file system start storing at the first free cluster available. So if we want to store a file which uses five clusters and the first gap is only four free clusters before a used/reserved cluster, the file will end up in two pieces. By adding and deleting files the data section will quickly be fragmented. Then why use FAT file system for Windows CE if devices are easily fragmented? Windows CE is built for minimalistic computers. The fragmented data section is not much of a problem since it normally deals with very little memory/storage space. For storage below 200 MB the FAT file system is probably quicker than most more advanced file systems. Few operations are needed to store a file because of the easy algorithm, and the main disadvantage about FAT file system is that if the storage space is large, it takes a lot of time to search the data, combined with the fact that it fragment easily. But since we in this case don't use large storage size, that is not a problem.
RTLinux RTLinux was developed by Victor Yodaiken and is an extension of the non- real- time OS known as Linux. It is currently available as a free version known as RTLinux Free, as well as a commercial version provided by FSMLabs known as RTLinux Pro. The main difference between the two is that the free version is open source while Pro is not, meaning that over the last 4 years FSMLabs programmers have been working to improve and almost completely rewrite RTLinux Pro's code while only contributions from people in the open source community has been added to the RTLinux Free code. RTLinux is used in the following areas (among others): Developing and testing jet engines for the US military. Simulating and testing weapon systems for the Comanche attack helicopter. Controlling Unmanned Aerial Vehicles. Driving advanced coal power plants. Onboard spacecraft control and management. Monitoring the performance of batteries in satellites. The way RTLinux and Linux relates is that RTLinux runs the non- realtime operating system Linux as a low- priority thread, and the data sharing between the two is done either by First- In- First- Out pipes or just a certain amount of shared memory space. The way this setup works is that the RTLinux core takes over the interrupt handling and personally handles all the interrupts required to execute hard real- time operations, while passing the rest of the interrupts on to the 'normal' Linux operating system running in the backgroun d, allowing them to be processed once all the realtime tasks have been taken care of. Thus the threads being scheduled by the real- time core can communicate with the programs being run in the non- real- time Linux, but the Linux kernel cannot affect the execution of the real- time operations in any way. As a result of this architecture, RTLinux can make use of all the different file systems that the 'regular' Linux OS supports. However, as RTLinux makes use of the POSIX 1003.13 standard, the RTLinux command 'open' will not support any other path names other than /dev/x for a certain amount of devices, where 'x' is the identifier for the specific device. Linux file systems Linux supports a wide range of different file systems. The different file systems that are currently being used by the OS are all tied together into a hierarchal tree structure which makes it seem as if it's all a single big file system. The way this works is that every file system is mounted onto a certain specified directory, effectively 'covering' the previous files in that directory with its own files until the time that it is unmounted again, at which point the original files of the directory is once again accessible. These kind of directories are referred to as either mount directories or mount points.
So basically in Linux it doesn't matter whether the file systems are on different hard drives being controlled by various hardware controllers or not, in fact you can even mount disks that are available over a network and it will still operate as if the file system would be on a disk inside the current computer. The interface layer that makes all of the above possible is known as the Virtual File System (VFS). The Virtual File System has been optimized so that the access to the files on any mounted file system is as fast and efficient as possible, while of course making sure that the data of the files are still stored correctly. The first file system to make use of the VFS was the extended file system (ext), which was specifically developed for Linux due to the constraints of the Minix file system which was used in the earliest versions of Linux. These constraints were due to the fact that the Minix file system was designed to be used in the Minix OS, which basically was a simpler version of Unix, and thus didn't have an awful lot of requirements when it came to the structure and efficiency of its file system. The extended file system The first version of the extended file system (ext) was introduced in 1992, and it was the first file system specifically designed for Linux. However, as even this version was soon found to lack quite a lot of performance, a second version was introduced a year later in 1993 and came to be known as the second extended file system (ext2). The second extended file system assumes that the data being stored in the files are organized in data blocks which are all of the same size. This size is specified by the user when the file system is created so it can vary between different ext2 file systems. The way these blocks work is that every file's size is divided over a integral number of blocks, so if the block length (size) is set to 512 bytes, a file with the total size of 5121 bytes will still take up 11 blocks even though only one byte of the last block is actually used. The reason that this kind of inefficient block allocation is used is to minimize the strain on the CPU when it comes to disk space utilization. However, not all of these data blocks actually contain file data, some are also used by the file system to store information describing its structure. Each file in the ext2 file system is described using what they refer to as an inode, which is a data structure with a unique identification number that describes which blocks the data of the file is stored in, the files access rights, modification times as well as the type of the file etc. Also, in the ext2 file system directories are just represented as special files which contain pointers to the inodes of their entries. The file system stores all of these inodes in specific inode tables.
The inodes contain the following information fields: Mode shows what the inode describes as well as what permission users have when it comes to altering it. Owner Information contains the group- and user- identifiers of the owners of the file or directory referred to by the inode, allowing the file system to know what kind of accesses should be allowed to the file by different users. Size shows the size of the file that the inode refers to (0 for directories). Timestamps displays the time that the inode was created as well as when it was last modified. Datablocks contains pointers to the blocks that store the data that the inode is describing. Something worth mentioning might be that inodes can also be used to describe special files known as device files, which aren't actual files but rather handles that the programs running in Linux can use to access attached devices. The ext2 file system divides the partition it resides on into something called Block Groups. Every group holds both files and directories in the form of information- and data- blocks, as well as a copy of any information that is vital for the file systems integrity, enabling a file system recovery to be made in the case of an occurrence of a corruption of some kind. Each one of these Block Groups contain among other things a table of inodes, as well as a bitmap tracking which inodes are in use and which aren't. The next upgrade to the extended file system was introduced in 2001 and had the following improvements: a journal (making ext3 a journaled file system), a tree- based directory indexes for directories occupying several data blocks, and finally the possibility for online file system growth. In ext3 there are three different levels of journaling available: Journal, Writeback and Ordered. Journal - Both metadata and the contents of the file are written to the journal, improving reliability at the cost of perfor ma nce. Writeback - Only metadata is written to the journal, giving better performance but radically reducing the reliability due to introducing the possibility of data at the end of files being corrupted if the file is being appended to during a systemcrash. Ordered - Only metadata is written to the journal as with Writeback, but it forces the contents of the files to be written before the metadata for the file is committed to the journal. This is the default level of journaling used in ext3 as it is considered to be a good enough compromise between reliability and performance.
The third and so far most recent upgrade was done in 2006 and resulted in what is called the fourth extended file system. This upgrade resulted in the system supporting volumes of up to 1024 petabytes (2 50 bytes) and added support for extents. An extent is basically a set amount of storage space that is allocated whenever you write to a file for the first time, so that when you later come back to writing to the same file your write instruction starts writing at the exact same data block where the previous write to the same file stopped, thus reducing or possibly even eliminating the risk of file fragmentation, all depending on the size of the extent.
Summary In summarization Windows CE is made for small applications and do not always need a file system. The standard file system RAM file system (Object Store) is used to organize data in files in the RAM. The RAM file system can then store save all the data on a ROM when needed. Windows CE can also use only the ROM file system and read/write small amounts of data when needed. These two types of file systems are most common among tiny applications that only need to save small amounts of data like configuration. For applications like a hand held computers where the user can store databases and custom files a more sophisticated but still easy file system like FAT can be handled. As stated above RTLinux supports all the file systems available for Linux, but due to using the POSIX1003.13 standard it is limited to confining itself to the folder /dev/x, where 'x' is the device identifier. Further information about Windows CE and RTLinux can be found at their official webpages 1,2. 1 Windows, Windows CE Homepage, <http:/ / m s d n.microsoft.com /embedded /windowsce/default.aspx> 2 FSM Labs, RTLinuxPro fsmlabs.com, <http:/ /www.fsmlabs.com /rtlinuxpro.html>
Conclusions The main difference between the file systems of RTLinux and Windows CE is that while RTLinux's file systems are the exact same file systems that are available for Linux, Windows CE has access to file systems that have been specifically designed for it. A result of this is that some of the Windows CE compatible file systems have been purely developed for use in real- time applications, while the RTLinux file systems (and the other Windows CE file systems) were designed for use in non- realtime operating systems. One thing about the file systems specifically designed for real- time operating systems is that they unlike many other file systems focus on optimizing themselves for small storage areas, whereas 'normal' file systems stride to support as large amounts of storage area as possible, and also happilly sacrifices some disk space to implement such things as journaling etc which on small disks might cut the effective storage area by as much as 50%. An example of this can be seen in Object Store in Windows CE where all the data is compressed to minimize storage space usage.
References 1) Windows, Windows CE Homepage, < http:/ / m s d n.microsoft.com/e mbedded /windowsce/default.aspx > 2) FSM Labs, RTLinuxPro fsmlabs.com, < http:/ /www.fsmlabs.com /rtlinuxpro.html >