Compatible Features
Compatible features are essentially nice-to-haves. In other words, if you support this feature, that is great, but if not, feel free to mount a filesystem using them as readable and writable. While you may mount this filesystem, you should not run the fsck (filesystem check) utility against it as you might break things associated with these optional features.
The compatible features list as of this writing is summarized in Table 7.2.
Table 7.2. Compatible Features.
| Bit | Name | Description |
|---|---|---|
| 0x1 | Dir Prealloc | Directory preallocation |
| 0x2 | Imagic inodes | Only the Shadow knows |
| 0x4 | Has Journal | Has a journal (Ext3 and Ext4) |
| 0x8 | Ext Attr | Supports Extended Attributes |
| 0x10 | Resize Inode | Has reserved Group Descriptor Table entries for expansion |
| 0x20 | Dir Index | Has directory indices |
| 0x40 | Lazy BG | Support for uninitialized block groups (not common) |
| 0x80 | Exclude Inode | Not common |
| 0x100 | Exclude Bitmap | Not common |
| 0x200 | Sparse Super2 | If set superblock backup_bgs points to 2 BG with SB backup |
The first feature in Table 7.2 is Directory Preallocation. When this feature is enabled the operating system should preallocate some space whenever a directory is created. This is done to prevent fragmentation of the directory which enhances performance. While this can be useful, it is easy to see why it is okay to mount the filesystem even if the operating system does not support this optimization.
Bit 2 (value of 0x04) is set if the filesystem has a journal. This should always be set for ext3 and ext4 filesystems. This is a compatible feature because it is (somewhat) safe to read and write a filesystem even if you are not writing through a journal to do so.
Bit 4 (value of 0x08) is set if the filesystem supports extended attributes. The first use of extended attributes was Access Control Lists (ACL). Other types of extended attributes, including user-specified, are also supported. We will learn more about extended attributes later in this chapter.
When the Resize Inode feature is in use, each block group containing group descriptors will have extra space for future expansion of the filesystem. Normally a filesystem can grow to 1024 times its current size, so this feature can result in quite a bit of empty space in the group descriptor table. As we will see later in this chapter, enabling certain features eliminates the storing of group descriptors in every block group.
Directories are normally stored in a flat format (simple list of entries) in extended filesystems. This is fine when directories are small, but can lead to sluggish performance with larger directories. When the Directory Index feature is enabled some or all directories may be indexed to speed up searches.
Normally when an extended filesystem is created, all of the block groups are initialized (set to zeros). When the Lazy Block Group feature is enabled, a filesystem can be created without properly initializing the metadata in the block groups. This feature is uncommon, as are the Exclude Inode and Exclude Bitmap features.
In a generic extended filesystem the superblock is backed up in every single block group. There are a number of features that can be used to change this behavior. Modern media are considerably more reliable than their predecessors. As a result, it makes little sense to waste disk space with hundreds of superblock backups. When the Sparse Super 2 feature is enabled the only superblock backups are in two block groups listed in an array in the superblock.
Now that we have learned about all the compatible features, we might ask which features affect the layout of our data. The two features in this category that affect the filesystem layout are Resize Inode and Sparse Super 2 which add reserved space in group descriptor tables and cause backup superblocks to be removed from all but two block groups, respectively.
How can you get enabled features and other information from a live Linux extended filesystem? Not surprisingly there are a number of tools available. The first tool is the stat (statistics) command which is normally used on files, but may also be used on filesystems. The syntax for running this command on a normal file is stat <filename>, i.e., stat *.mp3. The results of running stat on some MP3 files is shown in Figure 7.7. To run stat on a filesystem the command is stat -f
FIGURE 7.7
Running the stat command on regular files.
FIGURE 7.8
Running the stat command on a filesystem.
Like the stat command, the file command can be applied to files or filesystems. When run against files the file command will display the file type. Note that Linux is much smarter than Windows when it comes to deciding what to do with files. Linux will look inside the file for a file signature while Windows will stupidly use nothing but a file’s extension to determine how it is handled. The results of running file on the MP3 files from Figure 7.7. are shown in Figure 7.9. When run against a disk device the -s (special files) and -L (dereference links) options should be used. Figure 7.10 shows the results of running file -sL /dev/sd* on my laptop.
FIGURE 7.9
Output of file command when run against regular files.
FIGURE 7.10
Output of file command when run against hard disk device files.
From Figure 7.10 it can be seen that my Linux volume has journaling (not surprising as it is an ext4 filesystem), uses extents, and supports large and huge files. These features will be described in more detail later in this chapter.