Incompatible features
Incompatible features are those that could lead to data corruption or misinterpretation when a filesystem is mounted by a system that doesn’t support them, even when mounted read-only. Not surprisingly, the list of incompatible features is longer than the compatible features list. It should go without saying that if you should not mount a filesystem, it would be a very bad idea to run fsck against it. Incompatible features are summarized in Table 7.3.
Table 7.3
| Bit | Name | Description |
|---|---|---|
| 0x1 | Compression | Filesystem is compressed |
| 0x2 | Filetype | Directory entries include the file type |
| 0x4 | Recover | Filesystem needs recovery |
| 0x8 | Journal Dev | Journal is stored on an external device |
| 0x10 | Meta BG | Meta block groups are in use |
| 0x40 | Extents | Filesystem uses extents |
| 0x80 | 64Bit | Filesystem can be 2^64 blocks (as opposed to 2^32) |
| 0x100 | MMP | Multiple mount protection |
| 0x200 | Flex BG | Flexible block groups are in use |
| 0x400 | EA Inode | Inodes can be used for large extended attributes |
| 0x1000 | DirData | Data in directory entry |
| 0x2000 | BG Meta Csum | Block Group meta checksums |
| 0x4000 | LargeDir | Directories > 2GB or 3-level htree |
| 0x8000 | Inline Data | Data inline in the inode |
| 0x10000 | Encrypt | Encrypted inodes are used in this filesystem |
The Compression feature indicates that certain filesystem components may be compressed. Obviously, if your operating system does not support this feature, you will not be able to get meaningful data from the volume.
On extended filesystems the file type is normally stored in the inode with all the other metadata. In order to speed up certain operations, the file type may also be stored in the directory entry if the Filetype feature is enabled. This is done by re-purposing an unused byte in the directory entry. This will be discussed in detail later in this chapter.
The Recover feature flag indicates that a filesystem needs to be recovered. The journal will be consulted during this recovery process. While the journal is normally stored on the same media as the filesystem, it may be stored on an external device if the Journal Dev feature is enabled. The use of Journal Dev is not terribly common, but there are some situations where the performance improvement justifies the extra complexity.
The Meta Block Group breaks up a filesystem into many meta block groups sized so that group descriptors can be stored in a single block. This allows filesystems larger than 256 terabytes to be used.
The Extents feature allows more efficient handling of large files. Extents are similar to NTFS data runs in that they allow large files to be more efficiently stored and accessed. Extents will be discussed in detail later in this chapter.
The 64-bit feature increases the maximum number of blocks from 232 to 264. This is not a terribly common feature as 32-bit mode supports filesystems as large as 256 petabytes (256 * 1024 terabytes). It is more likely to be found when a small block size is desirable, such as with a server that stores a large number of small files.
The Multiple Mount Protection feature is used to detect if more than one operating system or process is using a filesystem. When this feature is enabled, any attempts to mount an already mounted filesystem should fail. As a double-check, the mount status (sequence number) is rechecked periodically and the filesystem is remounted read-only if the operating system detects that another entity has mounted it.
Like extents, flexible block groups are used to more efficiently handle large files. When the Flex Block Group feature is enabled, some of the items in adjacent block groups are moved around to allow more data blocks in some groups so that large files have a better chance of being stored contiguously. This feature is often used in conjunction with extents.
Extended attributes were discussed in the previous section. If extended attributes are supported, they may be stored in the inodes or in data blocks. If the Extended Attribute Inode flag is set, then the operating system must support reading extended attributes from the inodes wherever they exist.
We have seen several features that allow more efficient processing of large files. The Directory Data feature is an optimization for small files. When this feature is enabled, small files can be stored completely within their directory entry. Larger files may be split between the directory entry and data blocks. Because the first few bytes often contain a file signature, storing the beginning of a file in the directory entry can speed up many operations by eliminating the need to read data blocks to determine the file type. The Inline Data feature is similar, but data is stored in the inodes instead of the directory entries.
The remaining incompatible features are Block Group Meta Checksum, Large Directory, and Encrypt which indicate that checksums for metadata are stored in the block groups, directories larger than 2 gigabytes or using 3-level hash trees are present, and that inodes are encrypted, respectively. None of these three features are common.
For all of these incompatible features, we are most interested in the ones that affect our filesystem layout. There are three such features: Flexible Block Groups, Meta Block Groups, and 64-bit Mode. Flexible block groups combine multiple blog groups together in a flex group. The flex group size is normally a power of two. The data and inode bitmaps and the inode table are only present in the first block group within the flex group. This allows some block groups to consist entirely of data blocks which allows large files to be stored without fragmentation.
When meta block groups are in use, the filesystem is partitioned into several logical chunks called meta block groups. The group descriptors are only found in the first, second, and last block group for each meta block group.
The use of 64-bit mode does not directly affect the filesystem layout. Rather, the effect is indirect as some structures will grow in size when 64-bit mode is in use.