- Table of Contents
- Copyright
- About the Lead Authors
- About the Contributing Authors
- Acknowledgments
- Tell Us What You Think!
- Introduction
- I. Red Hat Linux Installation and User Services
- Chapter 1. Introduction to Red Hat Linux
- Chapter 2. Installation of Your Red Hat System
- Chapter 3. LILO and Other Boot Managers
- Chapter 4. Configuring the X Window System, Version 11
- Chapter 5. Window Managers
- Chapter 6. Connecting to the Internet
- Chapter 7. IRC, ICQ, and Chat Clients
- Chapter 8. Using Multimedia and Graphics Clients
- II. Configuring Services
- Chapter 9. System Startup and Shutdown
- Chapter 10. SMTP and Protocols
- Chapter 11. FTP
- Chapter 12. Apache Server
- Chapter 13. Internet News
- Chapter 14. Domain Name Service and Dynamic Host Configuration Protocol
- Chapter 15. NIS: Network Information Service
- Chapter 16. NFS: Network Filesystem
- Chapter 17. Samba
- III. System Administration and Management
- Chapter 18. Linux Filesystems, Disks, and Other Devices
- Chapter 19. Printing with Linux
- Chapter 20. TCP/IP Network Management
- Chapter 21. Linux System Administration
- Chapter 22. Backup and Restore
- Chapter 23. System Security
- IV. Red Hat Development and Productivity
- Chapter 24. Linux C/C++ Programming Tools
- Chapter 25. Shell Scripting
- Chapter 26. Automating Tasks
- Chapter 27. Configuring and Building Kernels
- Chapter 28. Emulators, Tools, and Window Clients
- V. Appendixes
- A. The Linux Documentation Project
- B. Top Linux Commands and Utilities
- C. The GNU General Public License
- D. Red Hat Linux RPM Package Listings
Creating New Filesystems
When you install Red Hat Linux, the installation process makes some new filesystems and sets up the system to use them.
Many operating systems don't distinguish between the preparation of the device's surface to receive data (formatting) and the building of new filesystems. Linux does distinguish between the two, principally because only diskettes need formatting and also because Linux offers as many as half a dozen different filesystems that can be created (on any block device). Separately providing the facility of formatting diskettes in each of these programs is poor design and requires you to learn a different way of doing it for each kind of new filesystem. The process of formatting diskettes is dealt with separately. (See the section Floppy Disk Drivers later in this chapter for more information.)
Filesystems are initially built by a program that opens the block device and writes some structural data to it so that when the kernel tries to mount the filesystem, the device contains the image of a pristine filesystem. This means that both the kernel and the program used to make the filesystem must agree on the correct filesystem structure.
Linux provides a generic command, mkfs, that enables you to make a filesystem on a block device. In fact, because UNIX manages almost all resources with the same set of operations, mkfs can be used to generate a filesystem inside an ordinary file! Because this is unusual, mkfs asks for confirmation before proceeding. When this is done, you can even mount the resulting filesystem using the loop device. (See the section Mounting Filesystems on Files later in this chapter for more information.)
Because of the tremendous variety of filesystems available, almost all the work of building the new filesystem is delegated to a separate program for each; however, the generic mkfs program provides a single interface for invoking them all. It's not uncommon to pass options to the top-level mkfs (for example, -V to make it show what commands it executes or -c to make it check the device for bad blocks). The generic mkfs program also enables you to pass options to the filesystem-specific mkfs. Most of these filesystem-dependent options have sensible defaults, and you normally do not want to change them. The only options you might want to pass to mke2fs, which builds ext2 filesystems, are -m and -i. The -m option specifies how much of the filesystem is reserved for root's use (for example, for working space when the system disk would otherwise have filled completely). The -i option is more rarely exercised and is used for setting the balance between inodes and disk blocks; it is related to the expected average file size. As stated previously, the defaults are reasonable for most purposes, so these options are used only in special circumstances:
# mkfs -t ext2 /dev/fd0 mke2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09 Filesystem label= OS type: Linux Block size=1024 (log=0) Fragment size=1024 (log=0) 184 inodes, 1440 blocks 72 blocks (5.00%) reserved for the super user First data block=1 1 block group 8192 blocks per group, 8192 fragments per group 184 inodes per group Writing inode tables: done Writing superblocks and filesystem accounting information: done # mount /dev/fd0 /mnt/floppy/ # ls -la /mnt/floppy/ total 17 drwxr-xr-x 3 root root 1024 Jul 31 04:24 . drwxr-xr-x 4 root root 4096 Jul 23 09:56 .. drwxr-xr-x 2 root root 12288 Jul 31 04:24 lost+found # umount /mnt/floppy/
Here, you see the creating and mounting of an ext2 filesystem on a diskette. The structure of the filesystem as specified by the program's defaults are shown. There is no volume label, and there are 4,096 bytes (4KB) per inode (360 x 4 = 1,440). The block size is 1KB, and 5% of the disk is reserved for root. These are the defaults (which are explained in the manual page for mke2fs). After you have created a filesystem, you can use dumpe2fs to display information about an ext2 filesystem, but remember to pipe the result through a pager such as less because this output can be very long.
After creating the filesystem on this diskette, you can include it in the filesystem table by changing the existing line referring to a vfat filesystem on /dev/fd1 to the following:
/dev/fd1 /mnt/floppy ext2 user,sync,errors=continue 0 0
The first three columns are the device, mount point, and filesystem type, as shown previously. The options column is more complex than previous ones. The user option indicates that users are allowed to mount this filesystem. The sync option indicates that programs writing to this filesystem wait while each write finishes and only then continue. This might seem obvious, but it is not the normal state of affairs. The kernel normally manages filesystem writes in such a way as to provide high performance. (Data still gets written to the device, of course, but it doesn't necessarily happen immediately.) This is perfect for fixed devices such as hard disks, but for low-capacity removable devices such as diskettes, it's less beneficial. Normally, you write a few files to a diskette and then unmount it and take it away. The unmount operation must wait until all data has been written to the device before it can finish (and the disk can then be removed). Having to wait like this is off-putting, and there is always the risk that someone might copy a file to the diskette, wait for the disk light to go out, and remove it. With asynchronous writes, some buffered data might not have yet been written to disk. Hence, synchronous writes are safer for removable media.
The ext2 filesystem has a configurable strategy for errors. If an ext2 filesystem encounters an error (for example, a bad disk block) there are three possible responses to the error:
- Remount the device read-only— For filesystems that contain mostly unessential data (for example, /tmp, /var/tmp, or news spools), remounting the filesystem read-only so that it can be fixed with fsck is often the best choice.
- Panic— Continuing regardless of potentially corrupted system configuration files is unwise, so a kernel panic (a controlled crash—emergency landing, if you prefer) can sometimes be appropriate.
- Ignore it— Causing a system shutdown if a diskette has a bad sector is a little excessive, so the continue option tells the kernel to carry on regardless in this situation. If this actually does happen, the best thing to do is to use the -c option of e2fsck, for example, with fsck -t ext2 -c /dev/fd1. This runs e2fsck, giving it the -c option, which invokes the command badblocks to test the device for bad disk blocks. After this is done, e2fsck does its best to recover from the situation.
Creating and Editing Filesystems Graphically with fsconf and linuxconf | Next Section

Account Sign In
View your cart