Now we describe the most popular Disc File System Linux - EXT2. The first release of Linux used the MINIX 1 file system, which had short file names and the maximum file size 64 MB. The MINIX 1 file system was eventually replaced by the first extended EXT file system, which allowed to use longer file names and larger file sizes. Due to its low efficiency (in the sense of performance), the EXT system was replaced by its EXT2 sequence, which is still widely used.

The disk partition with EXT2 contains the file system with shown in Fig. 10.17 layout. Block 0 is not used by the Linux system and contains a computer load code. Following the block 0, the disk partition is divided into blocks of blocks (excluding the boundaries of the disk cylinders). Each group is organized as follows.

The first block is superblock (Superblock), which stores information about the layout of the file system, including the number of I-nodes, the number of disk blocks, the beginning of the list of free disk blocks (this is usually several hundred elements). Then follows the group descriptor containing information about the location of the bit arrays, the number of free blocks and I-nodes in the group, as well as the number of directories in the group. This information is important, since the EXT2 file system tries to distribute the directories evenly throughout the disk.

In two bit arrays, free blocks and free i-nodes are recorded (this is also inherited from the MINIX 1 file system and distinguishes it from most UNIX file systems, in which the list is used for free blocks). The size of each bit array is equal to one block. With the size of the block 1 KB, this scheme limits the size of the block blocks 8192 blocks and 8192 I-nodes. The first number is a real limitation, and the second is practically no. With blocks of 4 kb of numbers four times more.

Then the I-nodes themselves are located. They are numbered from 1 to some maximum. The size of each I-node is 128 bytes, and describes it exactly one file. The i-node contains account information (including the entire return call, which simply takes it from the I-node), as well as a sufficient amount of information to determine the location of all disk blocks that contain the file data.

Following the I-nodes are data blocks. All files and directories are stored here. If the file or directory consists of more than one block, then these blocks are not required to be continuous on the disk. In fact, the blocks of a large file are most likely scattered throughout the disk.

The corresponding catalogs I-nodes are scattered over all groups of disk blocks. Ext2 is trying to arrange ordinary files in the same block of blocks as the parent directory, and the data files are in the same block as the source code i-node (provided that there is enough space). This idea was borrowed from the Berkeley Fast File System file system (McKusick et al., 1984). Bit arrays are used to make rapid decisions regarding the selection

places for new file system data.

When new file blocks are highlighted, the EXT2 also makes a preemptive selection (preallocates) of several (eight) additional blocks for the same file (to minimize file fragmentation due to future record operations). This scheme distributes the file system throughout the disk. It also has good performance (due to its trend towards related location and reduced fragmentation).

To access the file, you must first use one of the Linux system calls (such as Open) for which you want to specify the path to the file. This path disassembled, and the components of its catalogs are extracted from it. If the relative path is specified, the search begins from the current catalog of the process, otherwise - from the root directory. In any case, the i-node for the first directory is easy to find: in the process descriptor there is a pointer to it or (in the case of a root directory) it is stored in a specific disc on the disk.

The directory allows you to use file names up to 255 characters (Fig. 10.18). Each directory consists of a certain number of disk blocks (so that the directory can be written to the disk atomino). In the directory, elements for files and directories are in a nonorticated order (each item directly follows the previous one). Elements cannot cross the boundaries of blocks, so at the end of each disk block usually there is a number of unused bytes.

Each directory entry in Fig. 10.18 consists of four fields of fixed length and one field of variable length. The first field is an I-node number 19 for the Colossal file, 42 for the Voluminous and 88 file for the Bigdir directory. The following is the REC_LEN field, which reports the size of the entire directory entry in bytes (possibly, along with additional placeholders after the name). This field is necessary to find the next entry (in the case when the file name is complemented by an unknown number of bytes). In the figure, this field is indicated by the arrow. Then there is a field type field, a directory, etc. The last field of fixed length contains the length of the file name in bytes (8, 10 and 6 for this example). Finally, the file name comes in the zero byte itself and supplemented to a 32-bit border. Additional mailbox bytes can follow.

In fig. 10.18, B is shown the same directory after the element for the Voluminous was removed. All that is done in the catalog - increases the number in the recording size of the previous COLOSSAL file, and the directory entry bytes for the remote voluminous file are transformed into the first record fillers. Subsequently, these bytes can be used to record when creating a new file.

Since the search in directories is made linearly, then the search for a record that is at the end of a large directory may take a long time. Therefore, the system supports cache directories to which access has recently been made. The search in the cache is made by file name, and if it is found, then expensive linear search is no longer needed. The Dentry object is entered into the cache of the directory elements for each of the path components, and (through its I-node) is searching in the directory of the subsequent path items (until the actual file i-node is found).

For example, to find the file specified by the absolute path (such as / USR / AST / File), the following steps must be performed. First of all, the system finds the root directory, which usually uses an I-node with number 2 (especially when the I-node with number 1 is reserved to work with bad blocks). It places the corresponding element in the cache of the directory items (for future root catalog searches). It is then looking for a "usr" string in the root directory to get the number of the i-node for the / usr directory (which is also entered into the cache of the directory elements). This i-node is then read, and disk blocks are retrieved from it, so you can read the / usr directory and search for the AST line in it. After the corresponding element is found, you can define the number of the i-node for the / usr / ast. Having this I-node number, you can read it and find the directory blocks. Finally, we are looking for "File" and find the number of his I-node. Thus, the use of a relative path is not only more convenient for the user, but also reduces the amount of operation for the system.

If the file is available, the system retrieves the number of the i-node and uses it as an index of the i-node table (on the disk) to search for the corresponding I-node and read it into memory. This I-node is placed in the i-node table (I-Node Table) - the data structure of the kernel, which contains all I-nodes for the currently open files and directories. The format of I-nodes should contain (at a minimum) all fields that return the system call STAT so that the STAT call can work (see Table 10.10). In tab. 10.13 shows some of the I-node structure fields supported in the Linux file system. The actual structure of the I-node contains much more fields, since the same structure is used to represent directories, devices and other special files. The structure of the i-node also contains also reserved for future use of the field. The story has shown that unused bits are long remain without affairs.

Now let's see how the system reads the file. You remember that the typical call for the library procedure to start the system call reads as follows:

n \u003d read (FD, Buffer, Nbytes);

When the kernel receives control, then everything that it can start - these three parameters and information in its internal tables (related to the user). One of the elements of these internal tables is an array of file descriptors. It is indexed by file descriptors and contains one element to each open file (to some maximum amount, the default is usually 32).

The idea is to start with this file descriptor and finish the corresponding bubble. Let's look at one completely possible scheme: Let us place the pozel pointer to the file descriptors table. Despite the simplicity, this method (unfortunately) does not work. The problem is as follows. With each file descriptor, a pointer must be connected in the file that defines the byte in the file from which the next read or recording operation will begin. Where should this pointer be stored? One option is to place it in the Table of Buses. However, this approach will not be able to work if several processes that are not connected to each other simultaneously will open the same file, since each process should have its own pointer.

The second solution of the solution is to place the pointer in the table descriptors. In this case, each file opening the process has its own position in the file. Unfortunately, such a scheme also does not work, but the cause of failure in this case is not so obvious and is related to the nature of the sharing of files in the Linux system. Consider the shell script 5, consisting of two commands (P1 and P2), which should be performed in turn. If the script is called by the command line

it is expected that the P1 command will write its output to the X file, and then the P2 command will also write its output to the X file, starting from the place where the P1 command stopped.

When the shell starts the P1 process, the X file will first be empty, so the P1 command simply starts writing to the file in position 0. However, when P1 finishes its work, a certain mechanism will need that ensures that the P2 process will see as an initial position not 0 (and This is how it will happen if the position in the file descriptors in the file is in the table), and the value on which PI stopped.

The way it is done is shown in Fig. 10.19. The focus is to enter the new table - the open file description table (Open File Description Table) - between the table of file descriptors and the i-nodes table and store the pointer in the file (as well as the read / write bit). In the figure, the parent process is the shell, and the daughter is first the PI process, and then the P2 process. When the shell creates the PI process, its user structure (including the file descriptors table) is an exact copy of the same membrane structure, so both of them contain the pointers to the same table of description of open files. When the processpi completes its work, the shell file descriptor continues to specify the description table of open files, which contains the P1 position position in the file. When now the shell creates the P2 process, then the new child process automatically inherits the position in the file, while not a new process, nor the shell is obliged to know the current value of this position.

If any extraneous process opens the file, it will receive your own entry in the table description table with its position in the file, namely, it is necessary. Thus, the task of the open file description table is to allow parent and child processes to share one pointer in the file, but for foreign processes allocate personal pointers.

So (returning to the problem of reading reading read), we showed how the position in the file and the I-node are determined. The i-node contains disk addresses of the first 12 file blocks. If the position in the file falls into its first 12 blocks, the desired file block is read and the data is copied to the user. For files, the length of which exceeds 12 blocks, the I-node contains a disk address of the single indirect block (SINGLE INDIRECT BLOCK) (Fig. 10.19). This block contains disk addresses of additional disk blocks. For example, if the block size is 1 KB, and the disk address takes 4 bytes, the single indirect unit can store up to 256 disk addresses. This scheme allows you to support files up to 268 KB.

ext2. (also called as ext2fs.) - Second Extended File System(The second extended file system) is a file system built on the Linux kernel. The creator and developer EXT2 is Remy Card. The EXT2 file system was built by him in return for the old, the previous version - EXT.

According to such indicators as speed and performance, this file system can serve as a reference. This is told about the results of file system performance tests. For example, in tests for the speed of consistent reading and writing, which conducted the Dell Technical Center, the EXT2 file system exceeds ext3, and is inferior in reading speed only more modern EXT4.

The main disadvantage of ext2 is that it is not a journaling file system. However, this disadvantage was eliminated in the next file system - EXT3.

ext2 is used on flash cards and solid-state drives (SSD), since the lack of journaling is an advantage when working with drives with restrictions on the number of recording cycles.

The history of creating EXT2.

At the time of the rapid development of the Linux system, it used the MINIX file system. It was quite high stability, but it was 16-bit. As a result, it existed a strict limitation in 64 MB to the section. In addition, there was a limit on the maximum length of the file name, which was 14 characters.

These restrictions in the aggregate were the reason for the development of an "enhanced file system" (hence the term " Extended File System »). She had a task to solve two MINIX key problems. The new file system was published in April 1992. It was EXT, it expanded the limit on the size of the file to 2 gigabytes and installed the limit length of the file name in 255 characters.

However, despite the success of a new file system, however, there remained quite a lot of unresolved problems. For example, there was no support for separate access, there were no time stamps of data modification. The need to solve these tasks and served as the motive to create the next version of the extended Ext2 file system (" Second Extended File System »). Ext2 was developed in January 1993, it also implements the corresponding ACL access control lists and extended file attributes.

Logical organization EXT2.

EXT2 directory hierarchy graph is presented in the form of a network. This is due to the fact that one file can enter several directories immediately.

All file types have symbolic names. In hierarchically organized file systems, three types of names are used: simple, composite and relative. So in Ext2. In the case of a simple name, the restriction is that its length should not exceed 255 characters, in addition, the NULL symbol and slash must be present in the name.

As for NULL symbol, the restrictions are associated with the representation of rows in the SI language, in the case of a slash symbol, everything is that it is used as a dividing character between directories.

The full name is a chain of simple symbolic names of all directories through which the path from the root is running to this file. In Ext2, the file can enter several directories, it means that it can have several full names (one file is a few full names). But anyway, the full name defines the file.

Ext2 attributes:

• type and access rights to the file,
• owner, access group,
• information on permitted operations,
• creation time, last access date, last change date and last removal time,
• current file size
• file Specification:

• regular file
• catalog,
• the device byte-oriented device,
• file block-oriented device,
• named channel
• symbolic link

• number of occupied blocks,
• others

File attributes are contained in special tables, and not in directories, as it may be in simple file systems. As a result, the directory has a very simple structure consisting of two parts: the number of the index descriptor and the name.

Physical organization EXT2.

Structure of disk section

As part of EXT2, the following can be distinguished:

• blocks and blocks of blocks;
• index descriptor;
• superblock.

The entire disk partition space is divided into fixed blocks, blocks multiple sector size (1024, 2048, 4096 or 8192 bytes). The block size is specified when creating a file system on the disc section. All blocks are assigned sequence numbers. To reduce fragmentation and the number of movements of the hard disk heads, when reading large data arrays, the blocks are combined into groups.

The basic concept of the file system is an index descriptor (also called inode - information Node.). This is a special structure containing information about attributes and physical file location. Index decapstructors are combined into a table contained at the beginning of each block of blocks. Superblock is the main element of the EXT2 file system. It contains general information about the file system. Superblock is located in 1024 bytes from the start of the section. The integrity of the superblock determines the functionality of the file system. OS creates several backup copies of the superblock - in case of damage to the partition. In the next block after a superblock there is a global descriptor table - a description of block groups in the form of an array with general information about all block groups.

Blok group

All EXT2 block blocks are broken into groups. For each group, a separate entry is created in the global descriptor table. This entry stores the main parameters, like that: the block number in bitmaps and tables, the number of free blocks in the group, the number of index descriptors containing directories.

Bit Map Blok - This is a system in which each bit informs whether the file corresponding to it has a file. If the bit is 1, then the block is busy. A similar function is performed by a bitmap of index descriptors: it shows which index descriptors are busy, and which is not. The Linux kernel tries to evenly distribute inode directory in groups, and inode files - move to a group with a parent catalog. The remaining place appears in the table as data is assigned to storing files.

Data Addressing System

The data addressing system is one of the most serious and key components of the file system. Thanks to it, the desired file is among the many empty or busy blocks on the disk.

ext2 applies the following file block addressing scheme. For storing the file address, 15 fields are isolated, each of which consists of 4 bytes. If the file fits in 12 blocks, the numbers of the respective clusters are listed in the first twelve addresses. If the file size exceeds 12 blocks, the following field contains the cluster address in which the numbers of the following file blocks can be located. So, the thirteenth field is used for indirect addressing.

With the maximum size of the block in 4096 bytes, the cluster corresponding to the 13th field may contain up to 1024 numbers of the following file blocks. If the file size exceeds 12 + 1024 blocks, then the 14th field is used, in which the cluster address containing 1024 cluster numbers is located, each of which refers to 1024 file block. There is already a double indirect addressing. And if the file includes more than 12 + 1024 + 1048576 blocks, then the last 15th field for triple indirect addressing is applied.

Such a addressing system allows you to have files, over 2 TB with a maximum block size in 4096 bytes.

If you have two operating systems, Windows and Linux are installed, then you would probably like to be contained on the sections of the free operating system directly from under Windows without reloading the computer.

Unfortunately, the support of the Linux OS sections in Windows is not provided. And in vain. It seems to me that it might be a beautiful gesture from Microsoft.

The essence of the problem is that Windows uses the NTFS file system, and Linux has its own way to organize files, Extended File System, the latest version of which has sequence number 4.

Linux is more friendly to its users rather than her commercial sister: in Linux, the default is supported by the Windows NTFS file system. Of course, you will not be able to install Linux on the NTFS section, but you can read and write data from this.

Ext2 IFS.

Ext2 IFS supports Windows NT4.0 / 2000 / XP / 2003 / VISTA / 2008 versions of X86 and X64 and allows you to view the contents of Linux EXT2 sections, and can also record on them. The utility sets the EXT2FS.SYS system driver, which expands Windows capabilities and includes full support for EXT2 in it: partitions ext2 are assigned the letters of disks, and the files and folders are displayed on them in the dialogs of all applications, for example, in the explorer.

Ext2 FSD.

Ext2 FSD is a free driver for Windows systems (2K / XP / VISTA / 7 versions x86 and x64). Like the previous utility, which, in its essence, is also the driver, includes full support for the EXT2 file system in Windows.

LTools - A command line utility kit that allows you to read and record data on / from Linux EXT2, EXT3 and Reiserfs (standard Linux file systems) from the DOS or Windows.

There is a version of the program with a graphic shell (written on Java) - ltoolsgui, as well as a version with a graphic shell written on.

Ext2read.

For dessert as always the most delicious.

Ext2read is a utility based on a manager file, which allows you to view and write to the EXT2 / EXT3 / EXT4 sections. Supports LVM2 and that distinguishes it from other programs of this review, the EXT4 file system. Embedded support for recursive copying directories.

And here is the second dessert. Initially, it was said that a good gesture from Microsoft would be included support for Linux sections in Windows by default.

The gesture was still made on the 20th anniversary of Linux. See yourself.

That's all. Thanks for attention. I will go fight back from the May beetles. Their this spring is sooo a lot. 🙂

Vladimir Miskov

File System Architecture Ext2

The article discusses the logical structure of the EXT2 file system of the Linux operating system.

Basic components of the EXT2 file system

As in any UNIX file system, the following components can be distinguished as part of the Ext2 file system:

• blocks and blocks of blocks;
• iNFORMATION Node;
• superblock.

Blocks and blocks of blocks

The entire disk partition space is divided into fixed size blocks, multiple sector size - 1024, 2048 and 4096 bytes. The block size is indicated when creating a file system on the hard disk section. A smaller block size saves space on the hard disk, but also limits the maximum file system size. All blocks have sequence numbers. In order to reduce the fragmentation and the number of movements of the hard disk heads, when reading large data arrays, the blocks are combined into groups.

Information node

The basic concept of the file system is the information node, information node, or inode. This is a special structure that contains information about attributes and physical file location. The file attributes are its type (normal file, directory, etc.), access rights, owner identifier, size, creation time. Information on the physical location is a sequence of absolute block numbers containing file data.

Superblock

Superblock is the main element of the EXT2 file system. It contains the following file system information (incomplete list):

• the total number of blocks and inode in the file system;
• the number of free blocks and inode in the file system;
• file System Block Size;
• number of blocks and inode in the group;
• size inode;
• file System Identifier;
• number of the first data block.

In other words, this is a block number containing superblock. This number is always equal to 0 if the size of the file system block is greater than 1024 bytes, and 1, if the block size is 1024 bytes.

The functionality of the file system directly depends on the integrity of the superblock. The operating system creates several backup copies of the superblock to be able to restore it in case of damage. The main copy is located on the offset of 1024 bytes from the start of the section on which the file system is created (the first 1024 bytes are reserved for the operating system bootloader).

Early versions of the EXT2 file system created copies of the superblock at the beginning of each block of blocks. This led to a large loss of disk space, so later the number of backup copies of the superblock was reduced, and groups of blocks of 0, 1, 3, 5 and 7 were allocated for their placement.

Blok group format

The generalized structural diagram of the Ext2 file system is presented in Fig. one.

Almost all block groups have the same format. In each group, in addition to the information blocks, information about the employment of blocks and inode groups in the form of a bitmap is stored. The block of blocks 0 also includes superblocks and table descriptors of the groups that we will consider below.

Bitting Map of Employment Blocks is usually located in the first block of the group. If a backup copy is present in the group, the bitmap is located in the second block of the group. The size of the bitmap is one block. Each bit of this card denotes the state of the block. If the bit is set (1), the block is busy if the block is reset (0) - the block is free. The first block of the group corresponds to the zero bit of the card, the second block - the first bit, etc.

Inode, located within the same group, are collected in the table. In the Bite Employment Map inode Group each bit characterizes the status of the element in the Inode group table.

Each block of blocks is described using the block group descriptor. A group handle is a structure that contains information about the addresses of the bitmap of the blocks of the blocks, the Inode busy bitmap and the inode table of the corresponding group. All group descriptors are collected in the group descriptors table, which is stored in a group of blocks 0. Just as for a superblock, the operating system creates backup copies of the table descriptors.

File reading algorithm

Each inode, as well as the block, has a sequence number, unique within the file system, and contains information only about single file. Thus, to access the contents of the file, you need to know the sequence number of the corresponding inode corresponding to it.

As mentioned above, information about the physical file location is contained in Inode. This information is a sequence of 32-bit block numbers containing file data (Fig. 1). The first 12 numbers are direct links to information blocks (Direct Blocks Number). The 13th number is an indirect link (Indirect Blocks Number). It contains the address of the block in which the addresses of information blocks are stored. The 14th room is a double indirect link (Double Blocks Number), the 15th number is a triple indirect link (Triple Blocks Number).

The file name in Inode is not included, setting the conformity between file names and the inode sequence numbers is performed through the directories.

Catalogs

Files in UNIX and POSIX systems are stored in a tree hierarchical file system. The root of the file system is the root directory indicated by the "/" symbol. Each intermediate node in the file system tree is a directory. The final vertices of the file system tree are either empty directories or files. The absolute path name of the file consists of the names of all directories leading to the specified file, starting with the root directory. So, the track name /home/test.file means that the Test.file file is located in the home directory, which, in turn, is located in the root catalog "/".

Catalog, as well as the file, is described using Inode. The contents of the directory is an array of records, each of which contains information about the file that is "inside" the current directory.

The record of the directory has the following format:

• sequence number inode file;
• recording length in bytes;
• file name;
• the length of the file name.

The search for an inode file always starts with the root directory. For example, in order to obtain the inode sequence number in the root directory, the operating system must obtain the contents of the root directory, find it in it with the name of this file and remove the inode file number from this record.

The several inode numbers are reserved by the file system, their list is contained in the header file:

* Special Inode Numbers

#Define Ext2_Bad_ino 1 / * Bad Blocks Inode * /

#Define Ext2_Root_in 2 / * root inode * /

#Define Ext2_acl_idx_in 3 / * ACL inode * /

#Define Ext2_acl_Data_ino 4 / * ACL inode * /

#Define Ext2_Boot_Loader_ino 5 / * Boot Loader Inode * /

#Define Ext2_undel_dir_ino 6 / * undelete directory inode * /

To record the root directory, inode is reserved at number 2 (root inode). This inode is in the block of blocks 0 and takes the second position in the inode table of this group. The number of the first non-surtered inode is stored in the superblock.

After determining the inode sequence number, the kernel calculates the group number in which this inode is located, and its position in the inode group table. Considering Inode from this position, the operating system receives full file information, including block addresses in which the contents of the file are stored.

The number of the block in which is located inode is calculated by the formula:

group \u003d (inode_num - 1) / inodes_per_group

where:

• group.- the desired number of the block block;
• inode_num - the sequence number inode defining the file;
• inodes_per_group - The number of inode in the group (this information is in the superblock).

The INODE position in the inode group table is determined by the formula:

index \u003d (inode_num - 1)% inodes_per_grupa

where Index is an inode position in the table.

Consider an example of obtaining the contents of the Test.file file located in the root directory. To read the /test.file file:

• in the array of the root directory records, find an entry about this file;
• extract the sequence number of the inode file, calculate the group number in which this inode is located;
• from the descriptor of this group, you extract the address of the inode group table;
• calculate the INODE position in this table;
• read inode file;
• from inode to extract the address block addresses and read the information in these blocks.

In fig. 2 Details show the readings of the /test file. File.

Steps 1-6 - reading the root catalog:

1. From the group of blocks 0, the table descriptors are read.
2. From the table descriptors table, the group of blocks group 0 is retrieved and the address of the INODE group is read from it.
3. From the group of blocks 0 reads the inode table.
4. The inode sequence number of the root directory is fixed and equal to 2, so the second element is read from the INODE group 0, which contains the block address with the root directory content. Suppose that this unit is located in the block of A. Blocks.
5. From the group of blocks A is read by a block containing the records of the root directory.
6. A record of the entry named "Test.file" is searched. If such a record is found, the inode series "test.file" file is retrieved from it.

By defining the inode number, you can access the information blocks of the file (steps 7-11):

7. The group number is calculated in which this inode is located, and its position in the inode group table (suppose that the group number is equal to B, and the position in the table - x).
8. From the group descriptors table, remove the portion group descriptor B, and the address of the Inode table of this block of blocks is read from it.
9. The inode table is read from the B block group.
10. From the INODE table of the blocks of blocks B reads inode, located in position X.
11. From the read inode, the block addresses with the content file /test.File is retrieved and information is read from the block with the specified address.

Software implementation of the file reading algorithm

Source data: There is a partition of the hard disk on which the EXT2 file system is created. This section matches the device / dev / hda3 file. In the root directory of the section, the Home subdirectory is created, and it contains the Test.file file of the following content:

Would cytrus live in the south?

Yes, but a fake instance!

1234567890-=

Do not think bad, it is not nonsense, but a test exercise from the course of training of telegraphists in the troops of the communication of the former USSR!

Attention! One important point should be taken into account. The created file will not be immediately recorded on the disk, and first fall into the disk buffer. Attempting immediately to obtain the contents of the file according to the above algorithm will not lead to anything, since information about this file is not physically on the disk. It is necessary to "force" the system to record disk buffer on the disk. The easiest way to do this is to perform a reboot operation. Therefore, after the file is created, restart the system.

Our task is using the device / dev / hda3 file, to read the /home/test.file file using the method of direct access to its information blocks.

Consider the program implementation of the module that performs this operation.

Header Files:

#Include.

#Include.

#Include.

#Include.

#Include.

#Include.

The header file defines the structural types describing the main components of the EXT2 file system - Superblock, the block group descriptor, information node, directory entry.

Consider briefly fields that are included in each of these structures:

1. Struct EXT2_SUPER_BLOCK superblock structure:
   • __U32 s_inodes_count- the total number of inode in the file system;
   • __U32 S_BLOCKS_COUNT.- the total number of blocks in the file system;
   • __U32 S_FREE_BLOCKS_COUNT.- the number of free blocks;
   • __U32 S_FREE_INODES_COUNT.- the number of free inode;
   • __U32 s_first_data_block- number of the first data block (the block number in which the superblock is located);
   • __U32 S_LOG_BLOCK_SIZE. - This value is used to calculate the size of the block. The block size is determined by the formula: Block Size \u003d 1024<< s_log_block_size;
   • __U32 s_blocks_per_group - the number of blocks in the group;
   • __U32 s_inodes_per_group - the number of inode in the group;
   • __U16 s_magic - Ext2 file system identifier (0xEF53 signature);
   • __U16 s_inode_size - the size of the information node (inode);
   • __U32 s_first_ino. - number of the first non-surveyed inode.
2. Struct EXT2_Group_Desc Group Descriptor Design Structure:
   • __U32 bg_block_bitmap- bitmap of employment of the group blocks;
   • __U32 bg_inode_bitmap- Bitting Map of Employment inode Group;
   • __U32 bg_inode_table - address of the inode table.
3. Struct EXT2_INODE information node structure:
   • __U16 i_mode is the type of file and access rights to it. File type Define bits 12-15 of this field:
     • 0xa000.- symbolic link;
     • 0x8000.- normal file;
     • 0x6000.- block block device;
     • 0x4000- catalog;
     • 0x2000- symbolic device file;
     • 0x1000- FIFO channel.
   • __U32 I_SIZE. - size in bytes;
   • __U32 i_atime.- the last file access time;
   • __U32 i_ctime. - file creation time;
   • __U32 i_mtime.- the time of the last modification;
   • __U32 i_blocks. - the number of blocks occupied by the file;
   • __U32 i_block - Addresses of information blocks (including all indirect links).

The ext2_n_blocks value is defined in the file:

* Constants Relative To the Data Blocks

#Define Ext2_ndir_blocks 12.

#Define ext2_ind_block ext2_ndir_blocks.

#define ext2_dind_block (ext2_ind_block + 1)

#Define Ext2_tind_Block (ext2_dind_block + 1)

#Define Ext2_n_blocks (ext2_tind_block + 1)

4. Struct EXT2_DIR_ENTRY_2 directory entry structure:

#Define Ext2_Name_len 255.

• __U32 inode - inode number file;
• __U16 REC_LEN. - directory recording length;
• __U8 Name_Len.- the length of the file name;
• char Name. – file name.

We define the name of the section on which the file system is created, global structures and variables.

#Define Part_Name "/ dev / hda3"

sTRUCT EXT2_SUPER_BLOCK SB;

/ * buffer for storing table descriptors * /

unsigned char buff_grp;

unsigned Char Buff; / * Information buffer * /

iNT INDEV; / * Device file handle * /

iNT BLKSIZE; / * File System Block Size * /

We define several functions that we need to work:

Superblock reading function:

void read_sb ()

Memset (& sb, 0.1024);

We are shifted by 1024 bytes from the start of the section and read the superblock to the structure of the STRUCT EXT2_SUPER_BLOCK SB:

If (LSEEK (Indev, 1024.0)< 0) {

PERROR ("LSEEK");

EXIT (-1);

If (Read (Indev, CHAR * & SB, SIZEOF (SB))< 0) {

PERROR ("READ");

EXIT (-1);

Check the file system identifier:

If (sb.s_magic! \u003d Ext2_super_magic) (

Printf ("Unknown File System Type!");

EXIT (-1);

The value of ext2_super_magic is defined in the header file.

Displays information about the file system, which is located in Superblock:

printF ("Superblock Info -----------");

PrintF ("Inodes Count -% U", SB.S_INODES_COUNT);

PrintF ("Blocks Count -% U", SB.S_BLOCKS_COUNT);

Printf ("Block Size -% u", 1024<< sb.s_log_block_size);

Printf ("first inode -% d", sb.s_first_ino);

PrintF ("Magic - 0x% x", sb.s_magic);

PrintF ("Inode Size -% D", SB.S_INODE_SIZE);

Printf ("Inodes Per Group -% U", SB.S_INODES_PER_GROUP);

Printf ("Blosks Per Group -% U", sb.s_blocks_per_group);

PrintF ("First Data Block -% U", SB.S_FIRST_DATA_BLOCK);

Return;

Function reading table descriptors:

void read_gdt ()

Calculate the size of the file system block:

BLKSIZE \u003d 1024.<< sb.s_log_block_size

The group descriptors table is located in a block, which is located immediately behind the first data block (for superblock).

Read the table:

If (LSEEK (indev, (sb.s_first_data_block + 1) * Blksize, 0)< 0) {

PERROR ("LSEEK");

EXIT (-1);

If (Read (Indev, Buff_grp, Blksize)< 0) {

PERROR ("READ");

EXIT (-1);

Return;

Inode content feature by its number:

void get_inode (int inode_num, struct ext2_inode * in)

Input features of the function - the inode sequence number and the structure of the Struct EXT2_INODE.

STRUCT EXT2_GROUP_DESC GD;

U64 Group, Index, POS;

Calculate the number of the block group in which the inode is located with the inode_num sequence number:

Group \u003d (inode_num - 1) / sb.s_inodes_per_group;

From the table descriptors, remove the group descriptor and copy it to the STRUCT EXT2_GROUP_DESC GD structure:

Memset ((Void *) & GD, 0, SizeOF (GD));

Memcpy ((void *) & GD, BUFF_GRP + (Group * (SizeOF (GD))), SizeOF (GD));

Calculate the INODE position with the inode_num sequence number in the Inode table of the group group and read this inode in the structure of the STRUCT EXT2_INODE:

index \u003d (inode_num - 1)% SB.S_INODES_PER_GROUP;

POS \u003d ((__U64) GD.BG_INODE_Table) * Blksize + (index * sb.s_inode_size);

Pread64 (Indev, in, sb.s_inode_size, POS);

Return;

Data block read function:

void Read_Iblock (struct ext2_inode * in, int blk_num)

U64 POS;

Input function parameters - Inode structure and block number (meant number from the address block sequence located in Inode).

Calculate the offset to the information block on the section and read this unit into the global buffer Buff:

POS \u003d ((__U64) IN-\u003e I_BLOCK) * Blksize;

Pread64 (Indev, Buff, Blksize, POS);

Return;

Function for receiving the contents of the root catalog:

void get_root_dentry ()

STRUCT EXT2_INODE IN;

The inode sequence number of the root directory is known, so we get the contents of the inode of the root directory and read its contents in the buffer:

get_inode (ext2_root_ino, & in);

READ_IBLOCK (& IN, 0);

The Buff buffer will contain the contents of the root directory.

Return;

The function of receiving the inode number by file name:

int get_i_num (char * name)

Input function parameters - file name. Return value - the sequence number inode file.

Int i \u003d 0, REC_LEN \u003d 0;

STRUCT EXT2_DIR_ENTRY_2 DENT;

In Buff buffer, there is an array of directory entries. To determine the sequence number of the inode file, you must find in this array with the name of this file:

For (; I< 700; i++) {

Memcpy ((Void *) & Dent, (Buff + REC_LEN), SizeOF (DENT));

If (! Memcmp (dent.name, name, dent.name_len)) Break;

REC_LEN + \u003d DENT.REC_LEN;

Return dent.inode;

And now we write down the main function:

iNT MAIN ()

Variables and structures:

sTRUCT EXT2_INODE IN;

// Absolute Travel File Name

Unsigned char * Full_path \u003d "/home/test.file";

Unsigned char buff1;

Static int i \u003d 1;

INT N, I_NUM, OUTF, TYPE;

The first character in the absolute path name of the file should be a direct slash (/). Check it:

If (Full_path! \u003d "/") (

PERROR ("SLASH");

EXIT (-1);

Open the device file, read superblocks and table descriptors:

Indev \u003d Open (part_name, o_rdonly);

If (indev.< 0) {

Perror ("Open");

EXIT (-1);

Read_sb ();

Read_gdt ();

We get the contents of the root catalog:

get_root_dentry ();

Now the buff buffer contains all the records of the root directory (if you want, you can save them in a separate file). Now, having the root directory records, we can get to the contents of the test.file file using the above file read algorithm. For this purpose, we organize a cycle. In the body of the cycle, we will analyze the absolute path name of the file, highlighting its elements - subdirectories (it is one, home) and the name of the search file (test.file). For each element, we define the Inode's sequence number, we consider this inode and then obtain the contents of the zero block (from the sequence of address blocks located in Inode):

while (1) (

Memset (Buff1.0, SizeOF (buff1));

For (n \u003d 0; n< EXT2_NAME_LEN; n++, i++) {

Buff1 [n] \u003d FULL_PATH [i];

If (((Buff1 [n] \u003d\u003d "/") || (buff1 [n] \u003d\u003d "?")) (

I ++;

Break;

buff1 [n] \u003d "?";

For each element of the absolute path name of the file, we determine the inode sequence number, read this inode in memory and then obtain the contents of the zero block:

I_num \u003d get_i_num (buff1);

Get_inode (i_num, & in);

READ_IBLOCK (& IN, 0);

Display the file information (name, inode number, file size and its type):

PrintF ("Inode Number -% u", i_num);

Printf ("File Name -% s", buff1);

PrintF ("File Size -% u", in.i_size);

The file type is determined by the older four bits of the I_MODE field structure EXT2_INODE:

type \u003d ((in.i_mode & 0xf000) \u003e\u003e 12);

PrintF ("Type -% D", Type);

Switch (Type) (

Case (0x04):

PrintF ("(Catalog)");

Break;

Case (0x08):

PrintF ("(normal file)");

Break;

Case (0x06):

PrintF ("(block unit)");

Break;

Case (0x02):

Printf ("(symbolic device)");

Break;

Default:

PrintF ("(Unknown Type)");

Break;

Check the type of file. If this is a regular file - interrupt the cycle:

If (Type & 0x08) (

The buff buffer will be information read from the information blocks of the /Home/test.file file. We write this information to the file:

OUTF \u003d OPEN ("OUT", O_CREAT | O_RDWR, 0600);

WRITE (OUTF, BUFF, SIZEOF (BUFF));

Close (OUTF);

Break;

We leave:

Close (Indev);

Return 0;

On this consideration of the logical structure of the EXT2 file system.

(Second Extended File System).

· Forestry of Linux file systems

· Disc partition structure in ext2fs

·

· Catalogs

· Files devices

·

·

· Library EXT2FS

· Section of the Ext2FS system

· Calculation of privacy

Matfak

Prog.

2nd course 5th grams.

Chichirov Andrey

Falomethem EXT2FS (Second Extended File System).

Expirations of Linux File Systems

Linux variables were database based on the MINIX operative system. It would be a nominated discs between two systems than to have a new file system, so Linus Torvalds followed the subsection in the Linux miniX file system. While this file system was quite effective with a relatively small amount of errors.

However, the flashes associated with the MINIX file system are quite high, so they began to think over the new file system for Linux.

To control the implementation of the new file system in the Linux poison, a virtual file system (VFS) has been used. The VFS has been written by Chris Provenzano, and then the Linus Torvalds has passed it in integration into poison.

After installing in the VFS poison, the new Fal System Fal System (Extended File System) has been easy and added to the Linux 0.96c vexa. In the new file system, two substantial miniX systems were removed: its maximum volume could reach 2 gigabytes, and the maximum file name is 255 characters. It was an achievement with the MiniX file system, although some of the simply apparent are still typing. There was no subdependent access, modification of the index descippet and modify the cells of the file change. This file system used related lists to open with free blocks and index descppings, which greatly influenced the system of the system: with the lists of the lists became unspecified and doused, which used to file a file system.

The decision of these probe was the release of two new file systems in January 1993: XIA and EXT2FS (Second Extended File System). For the most part, the XIA file system was based on Minix with the addition of several new features. Basically it was the possibility of practicing with long file names, the approval of the discs of the larger volume and the tension of the cells of the file changes. With Fine Stones, EXT2FS was based on extfs with many improvements and additions. She also had the opportunity for the future.

When these two file systems were released, they were functionally pilingually. The XIA system was more reliable than ext2fs, due to its minimization. Errors in the EXT2FS system were unpaved on their more silent application, and a large number of new features and improvements have been added. The current EXT2FS file system is very reliable and has become a de facto Linux file system.

The following table provides common information about the functionality of functional features that are provided with dashed file systems.

	Minix FS.	Ext FS.	Ext2 FS.	Xia FS.
Maximum file system
Maximum File Length
Maximum File Name Length
Subsection of the Tower of Changes of File Changes
Ability to pace
Changeable PAZMP Bloka
Protection of infoment

If you need the length of the file name in EXT 2. It can be increased to 1012.

Ext2FS will penetrate some blocks for the root user. Usually it is 5% of the total, which allows the system administration to avoid lack of a hard disk scope of its filling it with the use of users of dpuugi users.

Disc partition structure in ext2fs

Hard disk manufacturers usually supply their products formatted at a low level. As far as I know, it means that all disk space with the help of special labels is broken by the "sectors", the size of 512 bytes. Such a disk (or disk section) must be prepared for use in a specific operating system. In MS-DOS or Windows, the preparation procedure is called formatting, and in Linux - creating a file system. Creating a file system ext2fs. It is to create in the disk section of a particular logical structure. This structure is built as follows. First, the boot area is allocated on the disk. The boot area is created in any file system. On the primary partition, it contains a boot entry - a code fragment that initiates the process of loading the operating system at startup. On other sections, this area is not used. All the rest of the disk space is divided into blocks. The unit may be size from 1, 2 or 4 kilobytes. The block is addressable by a unit of disk space. Selection of location files is carried out entire blocks, so when choosing the size of the block, you have to compromise. The large size of the block, as a rule, reduces the number of appeals to the disk when reading or writing a file, but it increases the proportion of an infrequently used space, especially if there are a large number of small files.

Blocks, in its area are combined into groups of blocks. Block groups in the file system and blocks inside the group are numbered sequentially, starting with 1. The first block on the disk has number 1 and belongs to the group with the number 1. The total number of blocks on the disk (in the disk section) is a disk volume divider expressed in sectors. And the number of block groups is not required to divide the number of blocks, because the last group of blocks may not be complete. The beginning of each block of blocks has an address that can be obtained as ((group number - 1) * (number of blocks in the group)).

Each group of blocks has the same structure. Its structure is presented in the following tablet.

Structure of the group of blocks of disk partition in ext2fs.

The first element of this structure (superblock) is the same for all groups, and all others are individual for each group. The superblock is stored in the first block of each group of blocks (with the exception of Group 1, in which the loading record is located in the first unit). Superblock It is the starting point of the file system. It has a size of 1024 bytes and always located on the offset of 1024 bytes from the start of the file system. The presence of several copies of the superblock is due to the extreme importance of this file system element. Superblock duplicates are used when restoring the file system after failures.

Information stored in the Superblock is used to arrange access to the other data on the disk. The superblock defines the size of the file system, the maximum number of files in the section, the amount of free space and contains information on where to look for unoccupied areas. When you start the OS, the superblock is read into memory and all changes in the file system first find the display in the copy of the superblock located in the OP, and are recorded only periodically. This allows you to increase system performance, as many users and processes constantly update files. On the other hand, when the Superblock is turned off, it must be written to the disk, which does not allow you to turn off the computer by simply turning off the power. Otherwise, with the next load, the information recorded in the Superblock will be not suitable for the real state of the file system.

Superblock has the following structure

Name of the field	A type	Comment
s_inodes_count	Ulong	Number of index descriptors in the file system
s_BLOCKS_COUNT.	Ulong	Number of blocks in the file system
s_R_BLOCKS_COUNT.	Ulong	Number of blocks reserved for superuser
s_FREE_BLOCKS_COUNT.	Ulong	The number of free blocks
s_FREE_INODES_COUNT.	Ulong	Counter of the number of free index descriptors
s_first_data_block	Ulong	The first block that contains data. Depending on the size of the unit, this field can be equal to 0 or 1.
s_LOG_BLOCK_SIZE.	Ulong	Logic block size indicator: 0 \u003d 1 KB; 1 \u003d 2 kb; 2 \u003d 4 KB.
s_LOG_FRAG_SIZE.	Long.	Fragment size indicator (it seems, the concept of a fragment is currently not used)
s_BLOCKS_PER_GROUP.	Ulong	Number of blocks in each block block
s_FRAGS_PER_GROUP.	Ulong	The number of fragments in each block block
s_inodes_per_group	Ulong	Number of index descriptors (inodes) in each block block
s_MTIME.	Ulong	The time when the file system was last mounted.
s_WTIME.	Ulong	Time when the last time was recorded in the file system
s_MNT_COUNT.	Ushort.	Meter of the Mounting File System. If this counter reaches the value specified in the next field (s_max_mnt_count), the file system must be verified (this is done when restarted), and the counter is reset.
s_MAX_MNT_COUNT	Short	The number determining how many times the file system can be mounted
s_magic	Ushort.	"Magic number" (0xEF53), indicating that the file system belongs to the EX2FS type
s_state.	Ushort.	Flags indicating the current status of the file system (whether it is clean (Clean), etc.)
s_ERRORS.	Ushort.	Flags that specify error messaging procedures (what to do if errors are found).
s_pad.	Ushort.	Filling
s_LASTCHECK.	Ulong	The time of the last file system check
s_CHECKINTERVAL	Ulong	Maximum period of time between file system checks
s_creator_os.	Ulong	Specifying on the OS type in which the file system is created
s_rev_level.	Ulong	Revision LEVEL file system.
s_RERVED	Ulong	Filling up to 1024 bytes

Following the superblock, a description of the Block Group (Group Descriptors) is located. This description is an array having the following structure.

Name of the field	A type	Purpose
bg_block_bitmap	Ulong	The address of the block containing the Bit Card blocks (BLOCK BITMAP) of this group
bg_inode_bitmap	Ulong	The address of the block containing the bitmap of index descriptors (inode Bitmap) of this group
bg_inode_table	Ulong	The address of the block containing a table of index descriptors (Inode Table) of this group
bG_FREE_BLOCKS_COUNT.	Ushort.	Counter of the number of free blocks in this group
bg_free_inodes_count	Ushort.	The number of free index descriptors in this group
bG_USED_DIRS_COUNT	Ushort.	The number of index descriptors in this group, which are catalogs
bg_pad.	Ushort.	Filling
bg_reserved.	Ulong	Filling

The size of the block description of the block can be calculated as (size_group_Blok_V_EXT2 * number_groups) / size_block (If necessary, rounded).

The information that is stored in the group description is used to find bit cards of blocks and index descriptors, as well as a table of index descriptors. Do not forget that blocks and blocks of blocks are numbered from 1.

Bit Map Block (Block Bitmap) is a structure, each bit of which indicates whether the corresponding block is assigned to it. If the bit is 1, then the block is busy. This card serves to search for free blocks in cases where it is necessary to highlight the location under the file, the bitmap of blocks occupies the number of blocks equal to (Number_Block_V_Group / 8) / Size_Block (If necessary, rounded).

The bitmap of index descriptors performs a similar function with respect to the table of index descriptors: shows which descriptors are busy.

The following area in the block structure structure serves to store the table of index file descriptors. The structure of the index descriptor itself is considered in the following subsection.

Well, finally, the remaining place in the block group is allocated to store actually files.

File systemEXT. 2 is characterized by:

• hierarchical structure
• agreed processing of data arrays,
• dynamic file extension,
• information security in files
• interpretation of peripheral devices (such as terminals and tape devices) as files.

Internal view of files

Each file in the EXT 2 system has a unique index. The index contains information necessary to any process to refer to the file. Processes refer to files using a clearly defined set of system calls and identifying the file string file acting as a composite file name. Each composite name definitely determines the file, so that the system kernel converts this name to the file index. INDEX includes a table of address location of the file information on the disk. Since each block on disk is addressed to its number, this table stores the set of disk block numbers. In order to increase flexibility, the kernel attaches to the file one by one block, allowing the file information to be scattered over the entire file system. But this placement scheme complicates the data search task. The addresses table contains a list of block numbers containing the file owned by the file, however, simple calculations show that a linear list of file blocks in the index is difficult to control. In order for a small index structure to work with large files, the disk block addresses table are brought into line with the structure shown in Figure 1

Most files in the EXT 2 system has a size that does not exceed 10 KB and even 1 KB! Since 10 KB file is located in the direct addressing blocks, to the most part of data stored in files, access can be made in one appeal to the disk. Therefore, in contrast to access to large files, working with standard size files proceeds quickly.

Index file descriptors

Each file on the disk corresponds to one and only one index file handle that is identified by its sequence number - the file index. This means that the number of files that can be created in the file system is limited by the number of index descriptors, which is simply defined when creating a file system, or is calculated based on the physical volume of the disk partition. Indian descpports exist on disk in static form and the kernel reads them in memory before starting with them to work.

The index file handle has the following structure:

Name of the field	A type	Description
I_Mode.	Ushort.	Type and access rights to this file.
I_UID	Ushort.	File owner identifier (Owner UID).
I_SIZE.	Ulong	File size in bytes.
I_atime.	Ulong	The time of the last access to the file (Access Time).
I_ctime.	Ulong	File creation time.
I_mtime.	Ulong	The time of the last modification of the file.
I_dtime	Ulong	File deletion time.
I_GID	Ushort.	Group identifier (GID).
I_LINKS_COUNT	Ushort.	Relations counter (Links Count).
I_blocks.	Ulong	The number of blocks occupied by the file.
I_Flags.	Ulong	File flags File Flags)
I_RERVED1	Ulong	Reserved for OS.
I_block	Ulong	Pointers to blocks in which file data is recorded (an example of direct and indirect addressing in Fig. 1)
I_VERSion.	Ulong	File version (for NFS)
I_file_acl	Ulong	ACL file.
I_dir_acl	Ulong	ACL catalog
I_faddr.	Ulong	Fragment Address (Fragment Address)
I_FRAG	Uchar.	Fragment Number (Fragment Number)
I_FSIZE.	Uchar.	Fragment Size (Fragment Size)
I_pad1	Ushort.	Filling
I_RERVED2.	Ulong	Reserved

The type field and access rights to the file is a two-byte word, each bit of which serves as a flag indicating the file ratio to a specific type or installation of one particular right to file.

Identifier	Value	Appointment flag (fields)
S_ifmt.	F000.	File type mask
S_ifsock.	A000.	Domain Nest (Socket)
S_IFLNK.	C000
S_IFREG.	8000	Normal (REGULAR) file
S_IFBLK.	6000	Block-oriented device
S_ifdir.	4000	Catalog
S_IFCHR	2000	Byte-oriented (symbolic) device
S_IFIFO.	1000	Named Channel (FIFO)
S_isuid	0800	Suid - Bit shift owner
S_isgid.	0400	SGID - group shift bits
S_ISVTX	0200	Task Conservation Bit (Sticky Bit)
S_irwxu.	01C0.	File owner's rights mask
S_irusr.	0100	Right to read
S_iwusr.	0080	Right to write
S_ixusr.	0040	Right to execute
S_irwxg.	0038	Group Mask Group
S_irgrp.	0020	Right to read
S_iwgrp.	0010	Right to write
S_IXGRP.	0008	Right to execute
S_irwxo.	0007	Mask of the rights of other users
S_IROTH	0004	Right to read
S_iwoth	0002	Right to write
S_IXOTH	0001	Right to execute

Among the index descriptors there are several descriptors that are reserved for special purposes and play a special role in the file system. These are the following descriptors

Identifier	Value	Description
Ext2_bad_ino.		The index descriptor in which the addresses of defective blocks on the disk are listed (BAD BLOCKS INODE)
Ext2_root_ino.		File System Root Directory Index Descriptor (ROOT INODE)
Ext2_acl_idx_ino		ACL inode
Ext2_acl_data_ino.		ACL inode
Ext2_Boot_Loader_ino.		Loader Index Descriptor (Boot Loader Inode)
Ext2_undel_dir_ino.		Undelete Directory Inode.
Ext2_first_ino.		The first non-pro-index descriptor

The most important handle in this list is the root directory descriptor. This descriptor points to the root directory, which, like all directories, consists of records of the following structure:

Name of the field	A type	Description
Inode	Ulong	file Index Descriptor Number (Index)
rEC_LEN.	Ushort.	Length of this record
name_len.	Ushort.	File name length
Name.	Char.	File name

A separate entry in the catalog cannot cross the block border (that is, it should be located entirely inside one block). Therefore, if the next entry does not fit entirely in this block, it is transferred to the next block, and the previous record continues in such a way that it fill in the block to the end.

Figure 1 Blocks of direct and indirect addressing in the index

Figure 2 Volume of the file in bytes at block size 1 KB

Figure 3. Example of disk index

Figure 3 shows the disk index of a certain file. This index belongs to the usual file, the owner of which is "MJB" and the size of which is 6030 bytes. The system allows the user "MJB" to read, write and execute the file; Members of the "OS" group and all other users are allowed only to read or execute the file, but not to record data into it. The last time the file was read on October 23, 1984 at 13:45, the record was the last time was made on October 22, 1984 at 10:30. The index changed the last time on October 23, 1984 at 13:30, although no information was recorded in this time. The kernel encodes all of the above data in the index. Pay attention to the difference in the record of the contents of the index and the contents of the file. The contents of the file changes only when the file is recorded. The contents of the index is changing both when changing the contents of the file and when changing the owner of the file, access rights and pointer sets. Changing the contents of the file automatically causes the index correction, but the index correction does not mean changing the contents of the file.

Catalogs

Catalogs are files from which the hierarchical structure of the file system is being built; They play an important role in turning the file name to the index number. The directory is a file containing which is a set of records consisting of the index number and the file name included in the directory. The composite name is a string of symbols, completed by an empty symbol and the inclined line shared ("/") into several components. Each component, in addition to the latter, must be a directory name, but the last component can be a file that is not a directory. In the V version of the UNIX system, the length of each component is limited to 14 characters; Thus, together with 2 bytes, allocated to the index number, the recording size of the directory is 16 bytes.

Offset in bytes Inside catalog	Index number (2 bytes)	Namefile
	1798	init
	1276	fSCK.
		cLRI
	1268	motd.
	1799	mount
		mknod.
	2114	passwd.
	1717	umount
	1851	checklist.
		fsdbld
		config
	1432	getty.
		crash.
		mkfs.

Figure 4 Catalog Format / ETC

Figure 4 shows the format of the "ETC" directory. Each directory has files, as the names of which are indicated point and two points ("." And "..") and index numbers that match the index numbers of this catalog and the parent catalog, respectively. Index number for file "." The "/ etc" directory has an address with offset 0 and value 83. The index number for the file ".." has an address with offset 16 from the start of the directory and the value 2. Entries in the directory can be empty, and the index number is 0. For example Recording with the address 224 in the "/ etc" directory is empty, despite the fact that it once contained the entry point for the file named "Crash". The MKFS program initializes the file system in such a way that index numbers for files "." And ".." The root directory coincides with the root index number of the file system.

The kernel stores the data in the directory in the same way as it does in the normal type file using the index structure and blocks with the levels of direct and indirect addressing. Processes can read data from directories in the same way as they read regular files, but the exclusive entry right to the directory is reserved by the core, which ensures the correctness of the directory structure. Catalog access rights have the following meaning: the right of reading gives processes the opportunity to read data from the catalog; Recording right allows the process to create new entries in the directory or delete old (using Creat, MKNOD, Link and Unlink system operations), as a result of which the contents of the catalog changes; The right of execution allows the process to search in the directory by the file name (since "executing" the catalog is meaningless).

When any program uses the path to the file, the corresponding nomep of the index descip contains in the catalogs. After the file name was used in the index descript number, this descippot is placed in memory and then used in subsequent zap.

The concept of UNIX file systems includes the concept of reference. One index descipboard can be associated with multiple file names. Deskpott is assisted by a field, a hinner, with which the file associates. Adding a link is to create a directory entry, where the index descippet number indicates a diskpot, and an increase in the reference counter in the descpport. You should delete the links of the poison reduces the reference counter and deletes the desqpot, if this meter becomes a null.

Such links are called rigid and can only be used in one file system (you can not create a link for a file system from a flip file system). Moreover, a rigid link can only specify a file (a strict reference to the directory can be used to focus in the file system).

In most UNIX systems, there is another type of link. These links that are promoting only the file name are called symbolic. You are using a poorer of such links, while using the path to the file to the index descipboard, the poison replaces the name of the reference to the descite software (i.e., in the name of the destination file) and re-Internet paths the path to the file. Since the symbolic link does not indicate the index desqpot, it is possible to create links to files that are located in a disinfined file system. These links may indicate a file of any type, even on a non-existent. Symbolic links are so used, as they do not have those fires that have a hard link. However, they occupy some volume on the disk, where the index descipboard and data blocks are allowed. Their use can be used to the discharge-related ways to use the path to the file to the index descipboard, which is due to the fact that the symbolization of the symbolic links of the poison should re-input the path to the file.

Files devices

In UNIX-like operating systems, access to devices is carried out through special files. This file does not take place in the file system. It is only an access point to the device drive.

There are two types of devices files: symbolic and block. When using a symbolic type, it is possible to exchange data with the device only in character mode, while block type devices files allow you to exchange only blocks using buffer. When requesting an I / O request to the device file, this query is redirected to the driver of the appropriate device. Each similar file corresponds to a senior number that defines the type of device, and the younger room that determines the device itself.

Additional features ext2fs.

In addition to UNIX, EXT2FS Standal features, there are some additional features that are usually not subsequently submitted by UNIX file systems.

File ATPIBUTs allow you to change the pressing of the polar using files with files. You can install on file or directory. In the second case, the files created in this directory inherit these atiquetic.

In the course of montization of the system, some particular features associated with file atiquotes can be installed. The MOUNT option allows the administration to select the features of creating files. In the file system with the features of BSD, files are created with the same Identifier GPPP, as well as the Apartment catalog. Features System V is somewhat more complicated. If the SETGID bit catalog is set, the files created by the identifier of the GPPs of this directory are received, and the subdirectories inherit the Identifies of the GPPP and the SETGID bits. In the present case, files and catalogs are created with the basic identifier of the GPPP of the causing PPCRESS.

The EXT2FS system may use a synchronous data modification similar to the BSD system. The MOUNT option allows the administration to specify all the data (index descplists, bits, indirect blocks, and directory blocks) recorded on the DC synchronously in their modifications. This can be used to achieve high information records, but also takes into a deterioration in the priesthood. In fact, this feature is usually not used, since the deterioration of the proliferation, this can be used to sweat users of users, which are not marked using the file system.

Ext2FS allows you to create a file system to select a logical block. It can be a pazmer 1024, 2048 or 4096 bytes. The use of a large volume blocks for the I / O optiating (as the amount of sucks to the disk decreases), and, therefore, to a smaller header of the heads. With the other side of the block, the use of a large block blocks to the dial of disk pension. Typically, the last block of the file is used not entirely for the field of information, therefore, with an increase in the volume of the block, the volume of the teped disk punch is increased.

Ext2FS allows you to use oskized symbolic links. Using such links, block data blocks are not used. The name of the destination file is not in the data block, but in the index descipboard itself. Such a structure allows you to maintain disk punch and evaporate the scotch of symbolic links. Of course, there is a piping, deskted under the descite, flaky, so not every link may be underwritten as hersal. The maximum length of the file name in a secondary link has 60 characters. In the near future, it is planned to pause this scheme for small volume files.

Ext2FS follows the state of the file system. Poor uses a separate field in the suspension to indicate the status of the file system. If the file system is mounted in read / write, its state is installed as "Not Clean". If it is dismantled or mounted again in the read-only enjoyment, then its condition is installed in "Clean". When the system of the system and the file system is underway, this information is used to operate the need for a file system. Poor also places some mischievous errors in this field. Opened non-compliance poison, the file system is marked as "Erroneous". The simulator of the file system will test this information for the system of the system, even if its condition is actually "Clean".

Prolonged Ignoring File System Testing Sometimes it may sometimes be with some sufficiency, so EXT2FS includes two methods for the regulatory system. The spearlock is promoted by the system mount counter. This counter increases each PA when the system is mounted in read / write feature. If its value reaches the maximum (it is also hudded in the suspension), then the file system testing is started by the checkout, even if its condition is "Clean". The latter, the first time and the maximum intelligent between the first is also hudded in the suspension. When the maximum intelligence is achieved between the pinks, the file system state is ignore and the checkpoint is started.

The EXT2FS system is assisted for its present. The Tune2FS bramma can be used to change:

• action PRI error unpacking. Opened with a non-compliance poison, the file system is marked as "erroneous" and one of the following steps can be performed: the implementation of the execution, the update of the file system in the read-only enjoyment in order to avoid its coupling, the system's paging system for the file system.
• maximum mounted value.
• maximum intelligence between the pins.
• the number of logical blocks, driven for the ROOT user.

Options specified by mounted can also be used to change the actions of the Obligation of the error poison.

Using ATPIBUT allows users to delete sequent files. You can delete a similar file, in blocks, which are used to use this file, is recorded by random info. This will be promoted to get access to the first-fold of this file in the authority, and the disk dial help.

The EXT2FS system recently added new types of files taken from 4.4 BSD file system. Putting-type files can only be used for reading: no one has to change them or delete them. This can be used to protect important configuration files. File type of files, these are files that can be turned into recording functions, and data can only be added to the end of this file. This type of files can also be removed or permanent. They can be used as zeper files that can only increase in volume.

Optimization of privity

The EXT2FS system is facilitated by many functions that optimize its profile, which leads to an increase in the scope of the exchange of information on reading and writing files.

Ext2Fs actively uses a disk buffer. When the unit must be read, the poison displays the I / O opt / output opaque. Thus, the poorer attempts to make sure that the next block, which should be read, is already in charge of a disk buffer. Such opporations are usually performed using serial reading files.

The EXT2FS system also provides a large amount of information optimizations. Blocks are used to combine the corresponding index descippets and data blocks. The poison always tries to squeeze the data blocks of one file in one gpup, as well as its desqpot. This is applied to reduce the proceedings of the header heads and the descript read and the corresponding data blocks corresponding to it.

These data records in the file, EXT2FS will reinforce up to 8 adjacent blocks using the new block. Such a method allows to achieve high-proceedability of the system's strengths of the system. It also allows you to use adjacent blocks for files, which fits their subsequent reading.

Library ext2fs.

To utilize the use of EXT2FS PESTS and the control of the contact stroits of this file system, LIBEXT2FS library has been easy. This library provides functions that can be used to operate and change these EXT2 file system by referring to physically eliminating.

Most EXT2FS utilities (MKE2FS, E2FSCK, TUNE2FS, DUMPE2FS, DEBUGFS, and DP.) Use this library. It strongly complements the modification of these utilities, as any changes to introduce additional features to the EXT2FS file system should be alone only in the EXT2FS library.

Since the EXT2FS Internet library is sufficiently shiyky and auxiliary, it can be easily written with its help, which will be easily written, for the work of which the file system can be used. Apply, the EXT2FS library was used by the 4.4 BSD dump and recovery of some utilities. It was killed to make very little changes to adapt these uses to Linux (it was necessary to replace several functions that interact with the file system to call to the EXT2FS library).

The EXT2FS library includes access to the operations of several classes. A puberty class is an opaque associated with the file system. Any shampoam can open or shift the file system, read or write bit block, create a new file system on the disk. There are also functions of the list of bad block system blocks.

The second class of opaque will use catalogs. Propamma using the EXT2FS library can create or scout a directory, as well as add or delete records in the directory. There are functions as propellants on the index descipping path to the file and the path of the path to the file according to the specified descip.

The last class of opaque opens with index descilepts. It is possible to read the descpport table, count or write down the descpotp, pp view all blocks of the specified desqpot. It is possible to proceed the functions of the formation and release of blocks and descpports.

Section of the Ext2FS system

For the EXT2FS system, powerful use of complementary use were used. These uses are used to create, modify and coppe any inconsistencies in EXT2FS file systems. The MKE2FS program is used to install a disk paste that provides an empty EXT2FS file system.

The Tune2FS application can be used for the power of the file system papalmet .C.C it may be changed to be changed to emerging errors, the maximum number of system mounting, the maximum intended between the system's progresses and the number of logical blocks driven for the root user.

Perhaps the most intelligent use is the simplified file system. E2FSCK PRACED To complete inconsistencies in the file system after the inaccation of the receipt of the entire system. The initial version of the E2FSCK Propamma is based on the Linus Torvald FSCK file for the Minix file system. However, the current versions of the transmanent period using the EXT2FS library and is more quick and can only be executed in a larger number of errors in the field of its inquiry, according to the preparation with a papaling vexa.

The E2FSCK shame was studied in such a time so that it was performed with the maximum speed. Since the pricks of the file system are called to the disk headband, you should optimize the E2FSCK flashing algorithms such, that the procedure for the file system should be used much easier. And, moreover, the deliberates of index descpts and directories would be performed according to the block number to reduce the disk drive heads.

In the breaking of the E2FSCK, the file system is pistened by all index descipients and the one descipputs as a separate element of the system. Such an occasion, these testing do not fit the File System Objects. One of the objectives of such pins is the input of the existence of the type of file type, as well as the correspondence of all blocks in the descpeppet with blocks with existing numbers. In the switchment, the bits are in operation indicating the use of blocks and descplists.

If the E2FSCK finds the data blocks, the noms of which are collected in more than one descip.

The nearest pepping takes up most of all, since all index descippets must be read into memory and inseparable. To reduce the input / output opections in subsequent bodies, all the necessary info movement remains in the buffer. A happotable read of this scheme is to search for all blocks of the file system directory. To obtain this information, the sequences of all file system directories are read in the second trips.

In the second trim, the directories are typing as individual elements of the file system. The block of each directory is separate, without a reference to the dpuch directory blocks. This allows E2FSCK to disconnect all the blocks of directories on the number of blocks and contact them in the running time, such a time reducing access to the disk. Catalog blocks are tested for the correspondence of the reality of their records and that they contribute to the references to the descputs with existing number (as it was turned on in the breaking).

For the directory block in each schedule of the directory, the existence of entries will be existed. "." and "..", and that the descppet number is for recording. " Corresponds to the current directory. (Scheduct Number for recording ".." does not test until it turns.)

When performing a second pHode, the info movement corresponding to the Apartment catalog is saved in the buffer.

It should be noted that by the end of the second pChoda, almost all input / output opections with a disc will be covered. All info movement, which tries for thousands of fourth and fifth trips, is promoted in memory, however, the remaining pits of the PPPSSOP and take less than 5-10% of the total E2FSCK execution.

Catalog connections are included in the trinket. E2FSCK does the paths of each directory to drink to bed, using the information obtained by the second pHode. Here is the record ".." for each catalog. All catalogs identified after the first and not having connections are placed in the / Lost + Found directory.

In the fourth, the E2FSCK trips, the reference counters for each index descip contains by ppplaying all descpports and reflect reference meters (this information is kept from a cross-boring) with internal meters, which the values \u200b\u200bof which were calculated in the sub-second and trunks. All failed files with zero reference meter are also placed in the / Lost + Found directory.

And finally, in the fifth, the E2FSCK is the correspondence of all information information on the file system. Here are the bits of blocks and descplists, which were obtained in the first-forthy pieces, with valid values \u200b\u200band, if necessary, the disk information on the disk appropriate occurs.

Use the useful use of the file system debugger. Debugfs is a powerful vanity that allows you to descend and set the file system status. Essentially, it is an interactive Internet to the EXT2FS library, that is, the typical commands to call the library functions.

Debugfs can be used to operate internal file system stricture, leaving the recovery system or creating conditional tests for E2FSCK. Unfortunately, this jammy can win the file system if you do not know how to use it. With this force, it is enough to destroy the file system. Therefore, Debugfs turns the file system in the default read-only position. To access the read / write envelope, you should specify the -W option.

Calculation of privacy

Bonnie test results are visible from the following table:

	Sugar recording (CB / s)	Patch entry (CB / s)	Performance (KB / s)	Sugar reading (CB / s)	Piece reading (KB / s)
BSD Async.
BSD Sync.
Ext2 FS.		1237			1033
Xia FS.

The results are sufficiently familiar with block input / output: the EXT2FS system wins on the reference system. This is due to the optimization included in the PA approximation. The entry is also fast enough, according to the fact that it is puppier in the Gupiene Purem. The high speed of reading is related to the fact that the blocks were pulled into a file, so the heading heads are not performed between two readings and the optimization of the first reading fully will fully.

With the other side of the side, the FreeBSD system includes a symbolic input / output of the reference value above. Perhaps this is due to the fact that FreeBSD and Linux use the appropriate with libraries corresponding to the corresponding c libraries. In addition, in FreeBSD, the more optimized symbolic reading library and therefore there is a bit better here.

Test results Andrew.

Andrew test results are visible from the following table:

	POPE 1 CREATING	Plumbing 2 Copying	Plumbing 3 status	Plumbing 4 Bapti	Plumber 5 compilation
	2203	7391	6319	17466	75314
BSD Sync.	2330	7732	6317	17499	75681
Ext2 FS.

The results of the past two pits show that Linux will win asynchonal data exchange. You are creating directories and files, the BSD system synchronously records the descpports and records of directories. There is a call that the asynchpone subdepending for FreeBSD has not yet been fully implemented.

In the tribute to the value of Linux and BSD are very similar. While when the BSD is described above, adding a bouquency for file names to the Linux VFS system is set to this type.

In the fifth and fifth PPODs, Linux will be quickly freeBSD, mainly on the use of combined bouquet use. The volume of the buffer can take more memory and take more memory than in FreeBSD, where the fixed volume is used. The results of EXT2FS and XIA FS responses show that optimization encountered in ext2fs is indeed used: the perpetrator of these systems is about 5-10%.

Conclusion

The EXT2 file system is the most shortly used in Linux users. She provides UNIX Standard Features and Additional Functions. Moreover, thanks to the optimization included in the poison, it shows excellent response results.

The EXT2FS system includes functions to add new features. Some people take care of the use of the PAs for the real file system: a list of access control, the corresponding POSIX Standa, restoring remote files and compress files in a long-scale residence.

First, the EXT2FS system was integrated into the Linux poison, and it is actively moving on the operation of the operating systems. Ext2FS is also an important component of the Masix Operation System, which is currently being studied by one of the autops.