嵌入式linux操作系统Chapter 7.doc

Chapter 8. Root Filesystem SetupHaving built the root filesystem and prepared the targets storage device, we are now ready to set up the root filesystem as it will be used on the target. First, we need to select a filesystem type for the root filesystem. Then, we need to convert the root filesystems content to the selected filesystem format or install the root filesystem on a device formatted for the selected filesystem type.This chapter begins by discussing the basic filesystem selection criteria. This is followed by a section describing how to use NFS to transfer filesystem images to the targets flash, a technique we use often in this chapter. We then concentrate on the setup of root filesystems for use on CRAMFS, JFFS2, NFTL, and RAM disks, respectively. Finally, we discuss the use of TMPFS for mounting certain directories, and how to update an embedded systems root filesystem dynamically. At the end of this chapter, the only issue remaining to getting a fully functional embedded system will be the setup and configuration of the bootloader. I will cover these issues in the next chapter.8.1 Selecting a FilesystemSelecting a filesystem type for your root filesystem is a delicate process. The final decision is often a compromise between the filesystems capabilities and the targets purpose. It is, for example, useless to choose a filesystem that provides persistent write storage, such as JFFS2, if the target never needs to permanently store any data. For such a target, a filesystem with no persistent storage, such as CRAMFS, is a much better choice.Furthermore, you may want to consider using many filesystems for the same system. A system that needs read and write access to temporary files only, for instance, could have most of its root filesystem mounted on CRAMFS while having its /var/tmp directory mounted on TMPFS or a RAM disk, and its /tmp being a symbolic link to /var/tmp.8.1.1 Characterizing FilesystemsTo select the best filesystem or best combination of filesystems for a certain application, we need to have a minimum set of characteristics that can be used to compare filesystems. Table 8-1 summarizes the characteristics of the filesystems typically used in embedded Linux systems. For each filesystem type, these are the questions used to characterize it:Write Can the filesystem be written to?Persistent Does the filesystem preserve modifications across reboots?Power down reliability Can a modified filesystem recover from a power failure?Compression Is the content of the mounted filesystem compressed?Lives in RAM Is the filesystems content first extracted from the storage device into RAM before being mounted?Table 8-1. Filesystem characteristicsFilesystemWritePersistentPower down reliabilityCompressionLives in RAMCRAMFSNoN/AN/AYesNoJFFS2YesYesYesYesNoJFFSYesYesYes1NoNoExt2 over NFTLYesYesNoNoNoExt3 over NFTLYesYesYesNoNoExt2 over RAM diskYesNoNoNoYes1 Extensive testing conducted by Vipin Malik shows that JFFSs power down reliability can fail. Such problems do not exist with JFFS2, however. See his article on JFFS and JFFS2 for the complete details: /articles/jffs_guide.html.As I said above, a system needs a write-capable filesystem only if it needs to update data found on that filesystem. Similarly, a system requires persistent writes only if the updated data needs to be preserved upon reboots. A system that does not provide write capability does not require persistent storage or power down reliability, since none of the data it stores is ever modified.Compression, on the other hand, is a desired characteristic of most filesystems, because it can lower the cost or increase the yield of storage in embedded systems. In some embedded systems, however, the increased cost, in CPU cycles, of compression and decompression may be undesirable.While most filesystems are mounted directly from their storage device, filesystems mounted on RAM disks must first be extracted from their storage device into RAM before they can be mounted. Because the original filesystem image on the storage device is never accessed directly, most filesystem images created for use with RAM disks are usually compressed before being placed on a storage device. We will discuss the creation of such compressed filesystem images for use with RAM disks in Section 8.6.Finally, no filesystem can be replaced while it is currently mounted. If a systems root filesystem is mounted from a JFFS2-formatted MTD partition, for example, the content of the MTD partition holding this filesystem cannot be overwritten with a new root filesystem. The only case where such a replacement is possible is when a filesystem is first copied into RAM before being mounted, as is the case of RAM disks. In that case, the actual media where the filesystem is stored is not accessed once the filesystem is mounted and can, therefore, be written over safely. As we shall see in Section 8.8, filesystems that are mounted in read and write mode from their original storage device can still be updated in various ways.As you will have noticed, Linux supports a great deal many more filesystems than I cover in Table 8-1. But most of these filesystems are not well adapted for embedded Linux systems. In addition, although I mention JFFS in the table above, we will not discuss it below, since it has been largely superseded by JFFS Guidelines for Filesystem SelectionNow that we have established a basic set of features for characterizing filesystems, lets review some general guidelines for selecting a filesystem configuration for your MTD-compatible storage device.ROMFS.Not for ROMsYou will notice a ROM file system support item in the File systems submenu of the kernel configuration menu. This filesystem is actually not intended for use with any form of physical ROM. Instead, it is mainly intended for use on disks for installation and troubleshooting purposes. ROMFS operates on block devices only, and does not interface with Linuxs MTD subsystem in any way. As the projects web site states, if you want to use ROMFS with a real ROM, you must first write a device driver for this ROM that makes it appear as a block device. See / for further information on ROMFS.If your system has a very small amount of flash but a relatively generous amount of RAM, a RAM disk is probably your best choice, because the filesystem living on a RAM disk is compressed in its entirety on the storage device. The compression ratio on the storage device obtained by using a filesystem on a RAM disk is actually much higher than what can be achieved with a natively compressed filesystem, such as CRAMFS or JFFS2, because such filesystems must still keep their metadata,2 among other things, uncompressed. The RAM disks edge in regards to on-storage-device compression are, however, offset by a higher RAM usage, since the entire filesystem lives uncompressed in RAM. Also, a RAM disk isnt appropriate if you need persistent data storage. Nevertheless, if your persistent data storage needs are limited, you can use a RAM disk for most of your root filesystem and mount only the data directories from a persistent filesystem such as JFFS2, as hinted to earlier. Also, using a RAM disk is often the easiest way to obtain a self-hosting target (which is a target that doesnt require a host to obtain its kernel or mount its root filesystem). x86 systems such as my DAQ module, for example, are the most likely to be shipped with RAM disks, since the prices for the components of such systems, including RAM, are low compared to other architectures. Note that although RAM can be cheap, it does consume more power than flash. Using large amounts of RAM for a RAM disk may, therefore, not be a viable option on some systems.2 This is the data stored by the filesystem to locate files and directories and maintain the filesystem structure in general.If your system has slightly more flash, or if you would rather save as much RAM as possible for the actual application running on your target and can spare a few extra CPU cycles for runtime decompression, CRAMFS is a very good candidate, granted the filesystems limitations we discuss in Section 8.3 arent a show stopper. Though CRAMFSs compression ratio is lower than a RAM disk, because of the reasons I outlined earlier, its capabilities are usually quite sufficient for most embedded applications that do not require persistent storage. As with RAM disks, nevertheless, you can mount the portion of the root filesystem that doesnt change at runtime on CRAMFS and the rest on a persistent filesystem such as JFFS2.CRAMFS will not be a viable option, however, if your target must be able to be upgraded in the field. For example, the iPAQ Familiar distribution project switched from CRAMFS to JFFS2 precisely because users were unable to update their iPAQs without reprogramming their devices flash. On the other hand, as another example, CRAMFS is a good candidate for my control module, because actual control procedures dont change very often in most industrial control applications.If you need to be able to change any portion of your filesystem at any time, JFFS2 is the best candidate. Though JFFS2 doesnt achieve compression ratios as high as CRAMFS, since JFFS2 has to maintain space for garbage collection and metadata structures that allow filesystem writing, JFFS2 does provide power-down reliability and wear-leveling, which are very important characteristics for devices that rely on flash storage, as we discussed in Chapter 3. My user interface modules, for example, would be completely based on JFFS2 to ease updating and extend the lifetime of the devices flash. At the time of this writing, however, JFFS2 is not a viable option if you are using a NAND flash device such as the DiskOnChip (DOC), as I explained in Chapter 3.If you are using a DOC device and need to be able to change any portion of your filesystem at any time, using a disk filesystem over NFTL is your only available option at the time of this writing. Most embedded x86 devices that are equipped with DOC devices have to use this configuration. My DAQ module, for instance, can be configured to store some of its samples locally from time to time to a disk filesystem mounted over NFTL.Strictly speaking, there is no such thing as a disk filesystem. I use this term here and in the rest of the book, however, to contrast filesystems typically used on block devices, such as ext2 and reiserfs, from filesystems typically used on MTD devices, such as JFFS2.Whether you are using CRAMFS, JFFS2, or a disk filesystem over NFTL, you may want to consider mounting some directories on TMPFS. Though the content of this filesystem is not saved to persistent storage, it does allow you to use part of the RAM to store temporary files such as those typically found in your root filesystems /tmp directory. If you are using a CRAMFS-based root filesystem, this allows you to have a directory, or a couple of directories, where you can both read and write files. If you are using either JFFS2 or a disk filesystem over NFTL, this allows you to avoid wearing out the storage device by manipulating data from RAM.Obviously, these are guidelines only, and each system likely imposes additional limitations that you have to take into account. Nonetheless, these guidelines represent the typical design trade-offs when building embedded Linux systems and they should give you a basic idea of how to choose your final setup. In the rest of this chapter, I will discuss the actual setup of the filesystems we discussed earlier and further detail their use.8.1.3 Filesystems for Disk DevicesIf you are using a conventional disk as your main storage device for your system, such as one that connects to the system using an IDE or SCSI interface, I suggest you take a closer look at the various filesystems currently used in desktop and server Linux installations. In particular, you will find journalling filesystems such as ext3 and reiserfs to be quite well adapted to environments that need power down reliability such as embedded systems. Because the use of these filesystems is already amply covered elsewhere and embedded systems use them no differently from their workstation or server counterparts,3 I will not discuss their use any further. I refer you to classic texts on the use of Linux on servers and workstations for further details on such filesystems. IBM developerWorks long series of articles by Daniel Robbins about Linux filesystems is of special interest here. In his series, Daniel provides in-depth discussion of the main journalling filesystems for Linux, including ext3, reiserfs, JFS, and XFS. See IBMs developerWorks site for Daniels articles: /developerworks/linux/. You may also be interested by Derek Vadalas Managing RAID on Linux (OReilly).3 As we discussed in Chapter 1, embedded Linux systems large enough to house actual physical hard disks have the equivalent processing power and RAM resources to deal with such storage.For a workstation- and server-oriented discussion of filesystems, see Chapter 6 of Running Linux.8.2 Using an NFS-Mounted Root Filesystem to Write a Filesystem Image to FlashThough we will discuss the setup and configuration of the NFS server on the host for providing a root filesystem to a target in detail in Chapter 9, lets take a look at how this configuration can be useful at this stage.The use of an NFS-mounted root filesystem during early development stages simplifies the development process by allowing quick modification of the files used by the target. Later, the target needs to have a filesystem stored in its flash in order to be self-hosting. Though some bootloaders can be used to copy images to flash, it is also possible to use the MTD utilities running on the target to copy files available on the NFS-mounted root filesystem to flash. To do so, copy the designated filesystem image to the directory containing the NFS-mounted target root filesystem, boot the target, and use MTD commands on the target to copy the filesystem image to flash.To copy an initial RAM disk image to your targets flash, for example, first configure your target to mount its root filesystem from a directory exported by your host using NFS. On your host, copy the filesystem image to the directory exported to your target. Though the filesystem image is not physically on your target, it will be visible on its root filesystem once the kernel mounts it using NFS at startup. Now, boot your target and use the MTD utilities on your target to copy the filesystem image from the NFS-mounted root filesystem to the appropriate flash device entry in your targets /dev directory.8.3 CRAMFSCRAMFS was written by Linus Torvalds as a filesystem with a bare minimum feature set. It is a very simple, and sometimes simplistic, compressed and read-only filesystem aimed at embedded systems. Apart from the characteristics summarized in Table 8-1, CRAMFS has the following limitations: The maximum size a file can have is 16 MB. There are no current (.) or parent (.) directory entries. The UID field for files is 16 bits wide and the GID field is 8 bits wide. Normal filesystems usually support either 16- or 32-bit UIDs and GIDs. On CRAMFS, GIDs are truncated to the lower 8 bits. In other words, the maximum GID usable in a root filesystem built on CRAMFS is 255.44 See Chapter 5 in Running Linux for a discussion about UIDs and GIDs. All file timestamps are set to epoch (00:00:00 GMT, January 1, 1970). The timestamps may be updated at runtime, but the updated values will last only as long as the inode is cached in memory. Once the file is reloaded, its timestamp will revert to epoch. CRAMFS images can be read only by kernels using 4096-byte page sizes (The value of PAGE_CACHE_SIZE must be 4096). All files, whether they are linked or not, have a link count5 of 1. Even when multiple filesystem entries point to the same file, that file has a link count of only 1. This is fine for most operations, however, since no files can actually be deleted from CRAMFS.5 As in other Unix systems, named links can be created toward files with most Linux filesystems. Typically, filesystems maintain a count of the number of links toward a file, and when this count reaches 0 the file is deleted.The truncated GIDs are not problematic if your targets root filesystem does not contain a group with a GID above 255. If your target is a single-user system, you dont need to worry about this limitation. If your system must support a multiuser environment, make sure the GIDs of all files and directories are below 255. Otherwise, any GID above 255 will wrap around to a number below 255 and, possibly, create a security risk. If you absolutely need a filesystem that can support at least 16-bit GIDs, you may want to consider using a disk filesystem over a RAM disk. It provides compression on the storage media, like CRAMFS, and also allows read and write access, instead of read-only access in the case of CRAMFS.In addition to CRAMFSs limitations, the tools provided for creating CRAMFS filesystem images used to be subject to the hosts byte ordering. Hence, you needed to use a host that had the same byte ordering as your target to create a CRAMFS image. The only way to bypass this limitation was to follow the technique I describe in Section 8.2. In essence, you had to mount the targets root filesystem on NFS, create the CRAMFS image for the target on the NFS-mounted filesystem, and write the created CRAMFS image to flash. Though, at the time of this writing, this limitation still applies to the CR