ext2

The ext2 or second extended file system was for many years the standard file system of Linux operating system and is still widely used (as of 2011 ). It was originally developed in 1993 by Rémy Card based on the Extended File System v1, which in turn originated from the Minix file system. The current implementation in the Linux kernel was created both by him and Theodore Ts'o and Stephen Tweedie. Furthermore, implementations for AmigaOS, FreeBSD, GNU Hurd, MiNT, MorphOS, NetBSD, OpenBSD, OS / 2, RISC OS and Microsoft Windows exist. Main disadvantage of ext2 is that it is not a journaling file system. It is increasingly losing so users on its backward-compatible successor to ext3 and other, newer file systems.

• 6.1 Symbolic Links
• 6.2 Device files

Specification

Ext2 shares many of its characteristics with traditional Unix file systems, such as the concept of blocks, inodes and directories. If desired, it can be extended with features such as access control lists, fragments, recovery of deleted data and compression. Most of these features are not implemented as standard, but exist only as patches. There is also a version mechanism, which allows to add new features backward compatible ( as is done in the journaling ext3 extension ). All information is stored on an ext2 system in " Little Endian " format, so that a file system on different architectures can be hung without causing incompatibilities.

Blocks

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

Block groups

To prevent fragmentation from the outset largely that would slow down the access to large amounts of consecutive blocks, blocks are grouped into block groups. The information on each block group is stored in a descriptor table that is right behind the superblock. Two blocks near the beginning of the block group are reserved for two bitmaps that indicate the block and inode allocation in the group. Since each bitmap can use only one block, the maximum size of each block group is limited ( in blocks ) to eight times the size of a block ( in bytes). The following bitmaps blocks contain the inode table for the block group, and the others are used as data blocks.

The superblock

The superblock contains all information about the configuration of the file system. The primary superblock is 1024 bytes after the beginning of the unit and is important in order to mount the file system ( mount ) can. 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 present in each block group, when the file system was involved, whether it be posted correctly last time was when it was changed, there is which version, and what operating system it has created. Because of damage to the superblock, the entire file system would be useless, be the superblock multiple copies, distributed in several groups of blocks saved. This superblock copies allow in case of failure to repair the original superblock.

If the file system or Revision 1 is new, there are other fields in the superblock, indicating the name of the volume, a unique identification number and the inode size, as well as provide space for the optional configuration information 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 the metadata on an object except for its name. The metadata includes permissions, owner, group, flags, size, the number of blocks used, access time, modification time, deletion time, number of links, fragments, version (used by NFS required), extended attributes, and any access control lists.

There are some unused fields and overloaded fields in the inode structure. A field is reserved for the directory access control list when the inode is a directory, alternatively maintains this field, the upper 32 bits of the file size if the inode is a regular file (this will allow files larger than 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 advanced access rights management and the inode of the program, which usually interprets this inode.

Are in the inode pointer to the first block 12, which contain the file's data. There is also a pointer to an indirect block ( which in turn contains pointers to the next set of blocks of the file), a pointer (contains the pointer to more indirect blocks ) to a double indirect block, and a pointer to a triply indirect block ( the pointers to double indirect blocks contain ).

The flags field contains some ext2 - specific flags that can not be influenced for example by chmod. These flags can be listed with the program lsattr and chattr be changed. These flags allow a file special behavior, which is not represented on the POSIX file Flags: There are flags for secure deletion, indelibility, compression, synchronous updates, write protection, indexed directories, journaling and more. Not all flags but are converted from ext2 driver in the kernel.

Directories and (Hard ) Links

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

A registered in the directory file name is called a link or hard link if the distinction from a symbolic link is to be emphasized. Behind this is a "N to 1 " relationship between links and files. The file consists of the user data and the inode is available only via a file path, ie a directory entry. As to a file as many directory entries can be created, it makes sense that you will not identify with the file, but to be understood as " references " to the file. Several links to a file can be in the same directory. In the inode of the file directory is performed on the number of links. After deleting the last link to a file, the file itself, so the inode and the payload data is released.

When creating a new directory file two links are identical adapted: one in the parent directory to the selected directory names, one with the name of the new directory itself subdirectories each have a shortcut named ".." to the parent directory of file ". ." The two links ". " And ".." are the same to the root directory of a file system.

Special Files

Symbolic links

Symbolic links ( symlinks ) are also filesystem objects with inodes. However, if the link is shorter than 60 bytes, their data is stored directly in the inode. Here, arrays are used that would normally hold pointers to data blocks. Since most links are less than 60 characters long, thus the use of a block for the symbolic link can be saved. Symbolic links can be used across file system boundaries ( multiple hard drives or partitions so as well). It may happen that the file referenced by the symbolic link is deleted, but the link remains. The link thus refers to a missing file and is therefore redundant.

Device files

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

Additional Attributes

In addition to the standard attributes has ext2 ( and ext3) ten extended attributes associated with, lsattr 'is displayed and, chattr ' can be set. The attributes of a directory are inherited to newly created underlying files. It is useful, for example, A ', which prevents the writing of the access time ( access time), which speeds up the access to the file. The "c" attribute ( compress) is not supported by the current kernel versions. There are, however extz ( = ext3 compression encryption). However, this project is no longer operated for some time.

Reserved Space

Within the file system can be a certain number of blocks for a particular user book, usually root for the system administrator. This allows the system to function even if non-privileged users have filled the entire space available to them. The mechanism works regardless of disk quotas. Furthermore, it helps to prevent complete filling of the file system, and so to control fragmentation.

File system check

During start up, most systems perform a consistency check ( e2fsck ) by its file systems. The superblock of the ext2 system contains multiple fields that indicate whether fsck should be run (because the file system check can take a long time if it is very large). fsck will run normally when the file system was not unmounted cleanly, or use a maximum time between two routine inspections has been exceeded.

Compatibility

Ext2 has a sophisticated compatibility mechanism that makes it possible to use File Systems in the kernel, the ext2fs driver of some functions used does not know anything. The compatibility mechanism is since ext2fs revision 1 available. There are three fields of 32 bits in length, one for compatible properties ( COMPAT ), one for read-only compatible features ( RO_COMPAT ) and one for incompatible properties ( INCOMPAT ).

A COMPAT -flag indicates that the file system contains a property, but the data format is 100 % compatible with older formats on the disk, so that a kernel that does not have this function, read and write to the file system could, without making it inconsistent. The best example of a COMPAT -flag is the function has_journal an ext3 file system. Building a kernel without ext3 support, such a file system problems mount as ext2fs and then write without the use of the journal it without damaging anything.

RO_COMPAT a flag indicates that the data format of the file system to read 100% compatible with older formats. A kernel without knowledge of the function in question, however, could corrupt the file system when he wrote it, so this is prevented. An example of a read compatible property is sparse_super, file system layout, with fewer superblock backups are stored as normal usual on the disk. An old kernel can be easily read from such a disk, if he would but take a writing test, would his writing routines produce misleading error messages and possibly the bitmaps are inconsistent.

A INCOMPAT -flag indicates that the data format has changed so that the kernel could not read or write or even just hang without this property. As an example of an incompatible auxiliary function can serve the optional compression; a kernel that can not decompress the data would only read "garbage" from the media. Also an inconsistent ext3 file system is incompatible long until an ext3 -enabled kernel read the journal and the inconsistencies has eliminated. After the ext3 system can be mounted as ext2 again.

Adding new features to ext2/3-Dateisystem always requires an update of the associated toolkit e2fsprogs, since testing tools contained therein must be able to know all the file system properties to enable it to ascertain and resolve inconsistencies.

File system boundaries

The causes of certain limits of the ext2 file system on the one hand be justified in the data format on the disk, on the other hand by the kernel of the underlying operating system. Most will be set once during the creation of the file system and depend on the selected block size and the selected ratio of blocks to inodes from. Block sizes of 8KB by default only on Alpha architectures are possible, as well as specially configured and patched other architectures. Regardless of the features of the kernel, some user space programs, which lack support for large files, manage files beyond 2 GiB incorrect.

The file system limits the number of subdirectories in a given directory to 32,000 pieces. Furthermore, is warning if more than about 10,000 to 15,000 files located in a directory that file operations could take in such large directories long. The actual maximum number of files is academic in nature, since it will already be difficult to generate enough file name before the limit of 130 trillion ( 1018) files per directory is reached.