ext2

from Wikipedia, the free encyclopedia
ext2
Manufacturer Rémy Card
Full name Second extended file system
Initial release January 1993 ( Linux )
Partition identifier Apple_UNIX_SVR2 ( Apple Partition Map )
0x83 ( Master Boot Record )
EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 ( GPT )
Technical implementation
Files Inode
Maximum values
Size of a file 2 TiB
Number of all files 10 18
Length of the file name 255 bytes
File system size 16 TiB
Allowed characters in the file name All characters except NUL and /
properties
Date range 1901-12-13 20:45:52 to 2038-01-19 03:14:07 ( UTC +0)
(see  year 2038 problem )
Forks supported
File rights management POSIX
Transparent compression optional (see below)
Transparent encryption No
Supporting operating systems Linux, BSD, Mac OS X,
Windows (through ext2 File System Driver or Ext2 IFS )

The second extended file system , or shortly ext2 , is the second extended file system for Linux - operating systems . It follows the original ext - file system , which in 1993 by Rémy Card based on the Minix file system was developed. Today's implementation in the Linux kernel comes from him as well as from Theodore Ts'o and Stephen Tweedie. ext2 was the standard file system for many Linux distributions for many years and was eventually replaced by more modern journaling file systems. The successors of ext2 are ext3 and ext4 , from which it has largely been replaced.

In addition to the source code in the Linux kernel, which is under GPLv2 , there are implementations for AmigaOS , FreeBSD , GNU Hurd , Mac OS X , MiNT , MorphOS , NetBSD , OpenBSD , OS / 2 , RISC OS and Windows under different licenses.

specification

ext2 shares many of its properties with traditional Unix file systems, such as the concept of blocks, inodes, and directories. If desired, it can be expanded to include features such as access control lists , fragments, recovery of deleted data and compression . Most of the functions mentioned are not implemented as standard, but only exist as patches . There is also a version mechanism that allows new functions to be added in a downwardly compatible manner (as was done with the journaling extension ext3 ). All information is stored on an ext2 system in “ Little Endian ” format, so that a file system can be mounted on different architectures without any incompatibilities occurring.

blocks

The space on a partition formatted with ext2 is divided into blocks. These have a fixed size of 1 KiB, 2 KiB or 4 KiB, block sizes of 8 KiB are also possible on Alpha processors . The size of the blocks is determined when the file system is created. Smaller blocks result in less wasted space per file, but require more overhead to manage and limit indirectly the maximum size of the files and the entire file system.

Block groups

In order to avoid fragmentation as far as possible from the outset, which would slow down access to large quantities of consecutive blocks, blocks are combined in block groups. The information about each block group is stored in a descriptor table which is located directly after the superblock. Two blocks near the beginning of the block group are reserved for two bitmaps that show the block and inode occupancy in the group. Since each bitmap can only occupy one block, the maximum size of each group of blocks (in blocks) is limited to eight times the size of a block (in bytes). The blocks following the bitmaps contain the inode table for the block group, and the others can be used as data blocks.

The superblock

The superblock contains all the information about the configuration of the file system. The primary superblock is 1024 bytes behind the beginning of the device and is important for integrating ( mounting ) the file system . The information in the superblock contains fields that specify, for example, the number of blocks and inodes in the file system, how many of them are free, how many inodes and blocks are in each block group, when the file system was mounted, whether it was unmounted correctly the last time when it was changed, which version is available, and which operating system has created it. Since the entire file system would be unusable if the superblock were damaged, multiple copies of the superblock are stored in multiple block groups. These superblock copies allow the original superblock to be repaired in the event of an error.

If the file system is revision 1 or newer, there are additional fields in the superblock that specify the name of the volume, a unique identification number, the inode size, and space for configuration information for optional file system functions.

Inodes

The inode (index node) is a fundamental concept in the ext2 file system. Each object in the file system is represented by an inode. The inode structure contains pointers (references) to the blocks in which the data of the object are stored and also all metadata about an object with the exception of its name. The metadata includes access rights, owner, group, flags, size, the number of blocks used, time of access, time of change, time of deletion, number of links, fragments, version ( required by NFS ), extended attributes and any access control lists .

There are some unused fields and overloaded fields in the inode structure. One field is reserved for the directory access control list if the inode is a directory, alternatively this field holds the upper 32 bits of the file size if the inode is a regular file (this allows file sizes over 2 GiB ). Most of the remaining fields are used by Linux and GNU Hurd as enlarged owner and group fields. GNU Hurd also knows additional fields for extended rights management and the inode of the program that usually interprets this inode.

In the inode there are pointers to the first 12 blocks , which contain the data of the file. There is also a pointer to an indirect block (which in turn contains a pointer to the next set of blocks in the file), a pointer to a double indirect block (which contains pointers to additional indirect blocks), and a pointer to a triple indirect block ( the pointer to double indirect blocks contains).

Additional attributes

The Flags field contains some ext2-specific flags that cannot be chmodinfluenced by , for example. These flags can be listed with the program lsattrand chattrchanged with. These flags allow a file to behave in a special way that cannot be represented by the POSIX file flags: There are flags for secure deletion, undeletability, compression, synchronous updates, write protection, indexed directories, journaling and much more. The attributes of a directory are inherited by newly created underlying files. However, not all flags are implemented by the ext2 driver in the kernel: the “c” (compress) attribute, for example, is not supported by the ext2 implementation of the Linux kernel. The extz project (= ext3 + compression + encryption), which has since been discontinued, was used for this.

Directories and (hard) links

A directory is a file system object and, like a normal file, has an inode. In principle, it is a special file that links each file name in the directory with an inode number. Newer versions of the file system also store the type of the object (file, directory, symbolic link , device, FIFO , socket ) in order to avoid the inode itself having to be checked for this information (in order to be able to use this, a newer version of glibc required).

A file name entered in the directory is referred to as a link or hard link if the distinction is to be emphasized compared to a symbolic link. Behind this is an "N to 1" relationship between links and files. The file, which consists of the user data and the inode, can only be used via a file path, i.e. a directory entry. Since any number of directory entries can be created for a file, it makes sense not to identify them with the file, but to understand them as "references" to the file. Several links to a file can be in the same directory. The number of links is kept in the inode of the file. After deleting the last link of a file, the file itself, i.e. the inode and the user data blocks, are released.

When creating a new directory file, two links are set up: One in the higher-level directory with the selected directory name and one with the name "." In the new directory itself. Subdirectories each have a link called ".." to the higher-level directory file. The two links “.” And “..” are identical for the root directory of a file system.

Special files

Symbolic links

Symbolic links are also file system objects with inodes. However, if the link is shorter than 60 bytes, its data is stored directly in the inode. Fields are used that would normally hold pointers to data blocks. Since most links are less than 60 characters long, this saves the use of a block for the symbolic link. Symbolic links can be used across file system boundaries (also across multiple hard drives or partitions). It can happen that the file to which the symbolic link refers is deleted, but the link remains. The link points to a file that no longer exists and has therefore become unusable.

Device files

Character and block oriented devices are never assigned data blocks. Instead, the device number assigned by the kernel is stored in the inode, whereby the pointer fields to data blocks are used again.

Reserved space

Within the file system, a certain number of blocks can be reserved for a certain user, usually the system administrator root . This allows the system to function even when unprivileged users have filled up all of the space available to them. The mechanism works independently of disk quotas . It also helps to prevent the file system from filling up completely and thus to combat fragmentation .

File system check

During the startup phase, most systems perform a consistency check ( e2fsck ) on their file systems. The ext2 system's superblock contains several fields that indicate whether it fsckshould be running (since checking the filesystem can take a long time if it is very large). fsckwill usually run if the file system has not been properly unmounted or a configurable maximum time between two routine checks has been exceeded.

compatibility

ext2 has a mature compatibility mechanism that allows file systems to be used under kernels whose ext2fs driver does not know anything about some of the functions used. The compatibility mechanism has been available since ext2fs revision 1. There are three fields, each 32 bit long, one for compatible properties (COMPAT), one for read-only features (RO_COMPAT) and one for incompatible properties (INCOMPAT).

A COMPAT flag means that the file system contains a property, but the data format on the disk is 100% compatible with older formats, so that a kernel that does not know this function could read and write in the file system without making it inconsistent . The best example of a COMPAT flag is the HAS_JOURNAL function of an ext3 file system. A kernel without ext3 support can easily mount such a file system as ext2fs and then write to it without using the journal, without damaging anything.

A RO_COMPAT flag indicates that the data format of the file system is 100% compatible with older formats when reading. However, a kernel with no knowledge of the function in question could corrupt the file system when writing to it, so this will be prevented. An example of a read-compatible property is SPARSE_SUPER, a file system layout in which fewer superblock backups than normal are stored on disk. An old kernel can read from such a hard disk without any problems, but if it tried to write, its write routines would produce misleading error messages and the bitmaps might become inconsistent.

An INCOMPAT flag indicates that the data format has changed in such a way that kernels without this property can neither write nor read or even mount. The optional compression can serve as an example of an incompatible additional function; a kernel that cannot decompress the data would only read “garbage” from the disk. An inconsistent ext3 file system is also incompatible until an ext3-capable kernel has read the journal and eliminated the inconsistencies. The ext3 system can then be re-attached as ext2.

Adding new properties to the ext2 / 3 file system always requires an update of the associated toolkit e2fsprogs , since the checking tools it contains must be able to know all file system properties in order to enable inconsistencies to be reliably identified and corrected.

File system limits

Boundary data of the ext2 file system on Linux
Block size: 1 KiB 2 KiB 4 KiB 8 KiB
Max. File size: 16 GiB 256 GiB 1 TiB 2 TiB
Max. File system size: 4 TiB 8 TiB 16 TiB 32 TiB

The reasons for certain limits of the ext2 file system can be based on the one hand in the data format on the data carrier and on the other hand in the kernel of the underlying operating system. Most of them are set once when the file system is created and depend on the selected block size and the selected ratio of blocks to inodes. By default, block sizes of 8 KiB are only possible on Alpha architectures, as well as on specially configured and patched other architectures. Regardless of the capabilities of the kernel, some user-space programs that lack large file support cannot properly handle files beyond 2 GiB.

The file system limits the number of subdirectories in a given directory to 32,000. Furthermore, if there are more than 10,000 to 15,000 files in a directory, a warning is given that file operations in such large directories could take a long time. The actual maximum number of files is academic in nature, as it will already be difficult enough to generate file names before the limit of 130 quintillion (10 18 is achieved) files per directory.

See also

Individual evidence

  1. ↑ Ext2 File System Driver (Ext2fsd) - enables native access to ext2 under Windows
  2. ↑ Ext2 Installable File System For Windows - enables native access to ext2 under Windows
  3. ↑ where 1 KiB = 1,024 bytes, 1 MiB = 1,024 KiB, 1 GiB = 1,024 MiB, 1 TiB = 1,024 GiB

Web links