Chapter 9: The Extended Filesystem Family
* about a feature in either the compatible or incompatible
* feature set, it must abort and not try to meddle with
* things it doesn’t understand...
*/
__le32 s_first_ino; /* First non-reserved inode */
__le16 s_inode_size; /* size of inode structure */
__le16 s_block_group_nr; /* block group # of this superblock */
__le32 s_feature_compat; /* compatible feature set */
__le32 s_feature_incompat; /* incompatible feature set */
__le32 s_feature_ro_compat; /* readonly-compatible feature set */
__u8 s_uuid[16]; /* 128-bit uuid for volume */
char s_volume_name[16]; /* volume name */
char s_last_mounted[64]; /* directory where last mounted */
__le32 s_algorithm_usage_bitmap; /* For compression */
/*
* Performance hints. Directory preallocation should only
* happen if the EXT2_COMPAT_PREALLOC flag is on.
*/
__u8 s_prealloc_blocks; /* Nr of blocks to try to preallocate*/
__u8 s_prealloc_dir_blocks; /* Nr to pre-allocate for dirs */
__u16 s_padding1;
/*
* Journaling support valid if EXT3_FEATURE_COMPAT_HAS_JOURNAL set.
*/
...
__u32 s_reserved[190]; /* Padding to the end of the block */
};The elements at the end of the structure are not shownbecause they are not used by Ext2 and are relevant
only in Ext3. Why this is so is explained in Section 9.3.
It is necessary to clarify various matters relating to the data types of these elements before going on to
define the meanings of the individual fields. As can be seen, the data types of most of the fields are named
le32,le16, and so on. These are, without exception, integers of anabsolutely definedbit length that
are represented in little endian byte order.^7
Why are no elementary C types used? Recall that different processors represent elementary types by
means of different bit lengths. Using elementary types would thus result in different superblock for-
mats depending on processor type — which is clearly no good. When removable media are swapped
between different computer systems, the metadata must always be stored in the same format, regardless
of processor type.
Other parts of the kernel also need data types of a guaranteed bit length that doesnotdiffer from pro-
cessor to processor. For this reason, the architecture-specific files containinclude/asm-arch/types.h
definitions for a series of types froms8tou64to control mapping onto the correct elementary data
types of the CPU type used. The endian-specific types are directly based on these definitions.
However, use of the correctlengthof a data type is, in itself, not enough. As established in Chapter 1,
the arrangement of the most significant and least significant parts of a multibyte data type also differs
depending on CPU type — again, we are faced with the problem of big and little endianness.
(^7) The distinction between little and big endian numbers does not influence the number of bits. The information can be used by auto-
mated source code analysis tools to ensure that no mistakes are made when the quantities are, for example, inspected bitwise.