home › Data recovery › Ext2 file system in Linux. How to access Ext2, Ext3, Ext4 file systems in Windows environment Ext2 file system

Ext2 file system in Linux. How to access Ext2, Ext3, Ext4 file systems in Windows environment Ext2 file system

How to make it possible to access a disk partition or removable media with file systems in a Windows environment Ext2/3/4 ? If, for example, there is also a second system on the computer Linux. And you need to work with its data from the environment Windows. Or another example - when virtual disks are mounted inside Windows with installed virtual machines systems Linux or Android. With Ext2/3/ 4 Windows cannot work natively; it needs third-party tools for this. What kind of means are these? Let's look at those below.

***
The first three tools will make it possible to only read information devices from Ext2/3/4. The latest solution will allow you to both read and write data. All the tools discussed below are free.

1. DiskInternals Linux Reader

A simple program is a primitive file manager, made like a standard Windows Explorer, with support for file systems Ext 2/3/4 , Reiser4 , HFS , UFS2. In the program window we will see partitions and devices with Linux or Android.

To copy, you need to select a folder or file, press the button "Save".

Then specify the copy path.

2. Plugin for Total Commander DiskInternals Reader

Fans of the popular can extract data Linux or Android inside Windows using this file manager. But first install a special plugin in it. One of these plugins is , it can connect and read information devices formatted in Ext2/3/4 , Fat/exFAT , HFS/HFS+ , ReiserFS. Download the plugin, unpack its archive inside , confirm the installation.

Let's launch (important) on behalf of the administrator. Let's go to the section. Click.

Here, along with other disk partitions and media, the one with Ext2/3/4 .

Data is copied traditionally way - by pressing F5 on the second panel.

3. Plugin for Total Commander ext4tc

A simplified alternative to the previous solution - ext4tc, another plugin for . It can connect to read information devices formatted only in Ext2/3/4. Download the plugin, unpack its archive inside the file manager, and start the installation.

Let's launch (important) on behalf of the administrator. Click. Let's go to .

If you need to copy data, use the usual method with the F5 key.

4. Ext2Fsd support driver

Program Ext2Fsd– this is the driver Ext2/3/4, it implements support for these file systems at the operating system level. You can work with disk partitions and drives formatted with these file systems as with regular Windows-supported media devices in an Explorer window or third party programs. The driver allows you to both read and write data.

Download the latest current version Ext2Fsd.

During installation we activate (if for long-term work) three suggested checkboxes:

1 — Driver autorun with Windows;
2 - Recording support for Ext2;
3 - Formatting support for Ext3.

At the pre-finishing stage, we activate the option to launch the driver manager window - - along with assigning information to devices from Ext2/3/4 drive letters.

In the window that opens We will see the media with the letter already assigned. For example, in our case, a carrier with Ext4 the first free letter is given F.

Now we can work with the disk F in the Explorer window.

Assign a letter to new connected devices with Ext2/3/4 can be done using the context menu called up on each of those displayed in the window devices. But simply by assigning a drive letter, such a device will not appear after reboot Windows, this solution is only for one computer session. To make a new device with Ext2/3/4 permanently visible in the Windows environment, you need to double-click on it to open the configuration window and set permanent connection parameters. In the second column you need:

For removable media, activate the checkbox indicated by number 1 in the screenshot and specify the drive letter;
For internal disks and partitions, activate the checkbox indicated in the screenshot below with the number 2, and also indicate the drive letter.

14 Jun

File systems ext2, ext3, XFS, ReiserFS, NTFS

File system- this is the order that determines the way of organizing, storing and naming data on any electronic storage media in computers.

The variety of file systems is explained by the fact that each was invented for its own specific set of tasks. Some write very quickly small files (say, up to 1GB), but at the same time interact poorly with large files or do not work with them at all. Some are good from a security point of view, others from a read/write speed point of view. Each file system has its own pros, cons, vulnerabilities and distinctive capabilities.

IN Linux The most commonly used types of file systems are:

ext2- stands for Second Extended File System(second extended file system). Developed by Remy Card in 1993 as a file system for the Linux kernel, from 1993 to 2001 it was the main file system Linux.
The advantage is high read/write speed.
The main disadvantage of the system ext2 is that it is not journaled, but precisely because of this it has great performance ( logging is a journaling process that stores a list of changes that helps maintain the integrity of the file system during various system failures);
ext3- stands for Third Extended File System(third version of the extended file system). Developed by Stephen Tweedy in 2001, still used today in distributions Linux. Was born as an improved ext2.
The advantage of this system is that it is journaled, that is, its reliability increases significantly compared to ext2.
The disadvantage is slightly lower performance and read/write speed.
XFS— Developed by the company Silicon Graphics in 1993, was added to the core Linux as a file system in 2002 across the entire family of distributions Linux, currently used as a “native” in the distribution Red Hat.
The advantage is the presence of metadata logging, high operational stability, the distribution of input/output streams into groups is supported, high read/write speeds, it is possible to defragment even when the partition is mounted, and you can increase the size of the file system. Works most effectively with large files.
The disadvantage is that the partition size cannot be reduced, the metadata processing process is not that fast, and it works noticeably slower with small files than other types of file systems.
ReiserFS- developed by the company Namesys under the direction of Hans Reiser in 2001. Only used on operating systems Linux. It was the first journaled file system to be adopted into the kernel.
The advantage of this file system is that it works very quickly with small files (read/write speed is higher than that of the ext4), supports logging.
The downside is that its development has slowed down noticeably due to the arrest of its leader, Hans Reiser, and there is no background encryption.
NTFS- stands for new technology file system(new technology file system). Developed in July 1993 by the corporation Microsoft. Widely used in various operating systems, as well as in various storage media.
The advantage is the built-in ability to limit access to data for different users, as well as assign restrictions on maximum volume disk space, use of a journaling system, high speed reading/writing of small files.
The disadvantage is that stable operation requires a large amount of PC RAM, it works slowly with large files, and the length of the path to the files is limited (32,767 Unicode characters).

In this simple way we figured out “file systems ext2, ext3, XFS, ReiserFS, NTFS«!

File system(English file system) - an order that determines the way of organizing, storing and naming data on information storage media of IT equipment (using portable flash memory cards for repeated recording and storage of information in portable electronic devices: digital cameras, mobile phones etc.) and computer equipment. It defines the format of the content and physical storage of information, which is usually grouped in the form of files. A specific file system determines the size of the file name (folder), the maximum possible file and partition size, and a set of file attributes. Some file systems provide service capabilities, such as access control or file encryption.

File system tasks

The main functions of any file system are aimed at solving the following problems:

file naming;

software interface for working with files for applications;

mapping the logical model of the file system onto the physical organization of the data storage;
organizing file system resilience to power failures, hardware and software errors;

In multi-user systems, another task appears: protecting the files of one user from unauthorized access by another user, as well as ensuring collaboration with files, for example, when a file is opened by one of the users, for others the same file will be temporarily available in read-only mode. .

A file system is the basic structure a computer uses to organize information on its hard drive. When installing a new hard drive it must be partitioned and formatted for a specific file system, after which data and programs can be stored on it. There are three possible file system options in Windows: NTFS, FAT32, and the rarely used legacy FAT system (also known as FAT16).

NTFS is the preferred file system for this version of Windows. It has many advantages over the older FAT32 system; Some of them are listed below.

The ability to automatically recover from some disk errors (FAT32 does not have this ability).
Improved support for large hard drives.
Higher degree of security. You can use permissions and encryption to deny user access to certain files.

The FAT32 file system and the rarely used FAT system were used in previous Windows versions, including Windows 95, Windows 98 and Windows Millenium Edition. The FAT32 file system does not provide the level of security provided by NTFS, so if your computer has a partition or volume formatted as FAT32, the files on that partition are visible to anyone who has access to the computer. The FAT32 file system also has file size limitations. In this version of Windows, it is not possible to create a FAT32 partition larger than 32GB. In addition, a FAT32 partition cannot contain a file larger than 4GB.

The main reason for using a FAT32 system is that the computer will be able to run either Windows 95, Windows 98, or Windows Millennium Edition, or this version of Windows (multiple operating system configuration). To create such a configuration, you must install the previous version of the operating system on a partition formatted as FAT32 or FAT, making it the primary partition (the primary partition may contain the operating system). Other sections accessed from previous versions Windows must also be formatted as FAT32. Earlier versions of Windows can only access networked NTFS partitions or volumes. NTFS partitions on the local computer will be inaccessible.

FAT – advantages:

It requires some RAM to work effectively.
Fast work with small and medium-sized catalogs.
The disk makes, on average, fewer head movements (compared to NTFS).
Effective work on slow disks.

FAT – cons:

Catastrophic loss of performance with increasing fragmentation, especially for large disks (FAT32 only).
Difficulties with random access to large (say, 10% or more of the disk size) files.
Very slow work with directories containing a large number of files.

NTFS - advantages:

File fragmentation has virtually no consequences for the file system itself - the performance of a fragmented system is degraded only in terms of access to the file data itself.
The complexity of the directory structure and the number of files in one directory also does not pose any special obstacles to performance.
Quick access to an arbitrary fragment of a file (for example, editing large .wav files).
Very fast access to small files (a few hundred bytes) - the entire file is in the same place as the system data (MFT record).

NTFS - cons:

Significant system memory requirements (64 MB is the absolute minimum, more is better).
Slow disks and controllers without Bus Mastering greatly reduce the performance of NTFS.
Working with medium-sized directories is difficult because they are almost always fragmented.
A disk that operates for a long time at 80% - 90% full will show extremely low performance.

The following file systems are considered as “native” for Linux (that is, those on which it can be installed and from which it can start): ext2fs, ext3fs, ext4fs, ReiserFS, XFS, JFS. They are usually offered as a choice when installing the vast majority of distributions. Of course, there are ways Linux installations to FAT/VFAT/FAT32 file systems, but this is only for those honeys and gentlemen who understand perversions, and I won’t talk about them.

The main criteria when choosing a file system are usually reliability and performance. In some cases, you also have to take into account the compatibility factor - in this case, it means the ability of other operating systems to access a particular file system.
I’ll start the review with ReiserFS - because the reason for writing this note was the question: what should be considered small files? After all, it is well known that the efficiency of working with small files is the strength of this file system.

So, small files mean files smaller than a logical block of the file system, which in Linux in most cases is equal to four kilobytes, although it can be specified during formatting within certain limits (depending on the specific FS). There are countless such small files in any Unix-like OS. A typical example is the files that make up the tree of FreeBSD ports, Gentoo portages, and similar port-like systems.
In most file systems, such mini-files have both their own inode (an information node containing meta information about the file) and a data block, which leads to both disk space consumption and a decrease in the performance of file operations. In particular, this is precisely the reason for the catastrophic thoughtfulness of the FreeBSD file system (both the old one, UFS, and the new one, UFS2) when working with its own system of ports.

In the ReiserFS file system, in such cases, separate blocks are not allocated for data - it manages to push the file data directly into the inode area. Due to this, disk space is saved and performance increases - literally several times compared to all other FS.
This handling of small ReiserFS files has given rise to the legend of its unreliability. Indeed, when the file system collapses (that is, the destruction of service areas), data located together with its inodes disappears along with them - and irrevocably. Whereas in those file systems where inodes and data blocks are always separated spatially, the latter can theoretically be restored. So, for ext2/ext3 there are even tools that allow you to do this.

However, like any legend, this one only gives the impression of authenticity. First, permanent data loss only applies to very small files. Among the user ones there are practically no such ones, and all the others can be easily restored from the distribution kit.
Secondly, when speaking about the possibility of recovering data from blocks that have lost their connection to their inodes, it was not by chance that I used the word “theoretical”. Because in practice this activity is extremely labor-intensive and does not give a guaranteed result. Anyone who has had to do this will agree that one can only indulge in it out of complete despair. And this applies to everyone file systems Linux. So this aspect can be neglected when choosing a file system.

In terms of overall performance, ReiserFS is definitely faster than all other journaled FS, and in some respects it is superior to ext2. A speed comparison of some common file operations can be found here.
But with ReiserFS the compatibility situation is somewhat worse. Access to it from Windows operating systems, as far as I know, is impossible. Some operating systems of the BSD family (DragonFlyBSD, FreeBSD) support this file system, but in read-only mode. Even the probability that an arbitrary Linux LiveCD from previous years does not have ReiserFS support is not zero.

And here it’s time to remember ext3fs. Its advantage is not at all in greater reliability - this is the same legend as the instability of ReiserFS. I have heard no less about ext3fs crashes than about similar incidents with ReiserFS. I myself could not destroy either one or the other. Except that it worked with ext2 - but even then a very long time ago, during the time of kernel 2.2 (or even 2.0).

No, the main advantage of ext3fs is its compatibility - it is guaranteed to be read by any Linux system. For example, when restoring from some ancient LiveCD at hand - a situation that is practically not so incredible, I had to get into it. Again, most BSD systems can easily understand ext3fs (albeit without logging). For Windows there are also, as far as I know, all kinds of drivers and plug-ins for common file managers(type Total Commander), providing access to partitions with ext2fs/ext3fs.

In terms of performance, ext3fs leaves a mixed impression. Firstly, its performance is very dependent on the logging mode, of which there are three: with full data logging, partial logging and logging only metadata. In each mode, it shows different performance on different types of file operations. However, in no case is the performance record-breaking.

However, if the performance requirement comes first, then ext2fs has no competition - however, in this case you will have to put up with the lack of logging at all. And, consequently, with lengthy checks of the file system in case of any incorrect shutdown - and with the volume of modern disks this can take a very long time...

The following can be said about XFS. In terms of compatibility, everything that was written for ReiserFS applies to it - moreover, until some time it was not supported by the standard Linux kernel. In terms of performance, XFS also does not shine, performing in total at approximately the same level as ext3fs. And the operation of deleting files generally demonstrates depressing slowness.
According to my observations, using XFS pays off when working not just with large, but with very large files - which are actually only DVD images and video files.

Let me return to the question of reliability. A banal power shutdown during normal user work, as a rule, is painlessly tolerated by all journaled file systems (and none of them ensures the safety of user operations not written to disk - rescuing drowning people remains the work of the drowning people themselves). True, for any file system it is possible to simulate a situation in which turning off the power will lead to more or less serious damage to it. However, in real life, such situations are unlikely to occur. And you can completely eliminate them by purchasing an uninterruptible power supply - it will give more confidence in the safety of data than the type of file system. Well, in any case, the only guarantee for restoring damaged data can be regular backups...

I think the information presented above is enough for an informed choice. My personal choice for the past few years has been ReiserFS. Occasionally, on systems where it is justified to move everything possible outside the root partition, it makes sense to use ext3fs for the root file system and ReiserFS for everyone else.

If a separate partition is provided for the /boot directory (and this is recommended when using GRUB bootloader by its developers) - for it, no other file system other than ext2fs is justified, any logging makes no sense here. Finally, if you create a separate partition for all kinds of multimedia materials, then you can think about XFS.

If we approach the explanation more methodically

ext - in the early days of Linux, ext2 (extended file system version 2) was dominant. Since 2002, it was replaced by the ext3 system, which is largely compatible with ext2, but also supports logging functions, and when working with kernel version 2.6 and higher, ACLs. The maximum file size is 2 TB, the maximum file system size is 8 TB. At the end of 2008, the release of ext4 was officially announced, which is backward compatible with ext3, but many functions are implemented more efficiently than before. In addition, the maximum file system size is 1 EB (1,048,576 TB), and you can expect this to be sufficient for some time. About reiser - the system was named after its founder, Hans Reiser, and was the first system with logging functions to access the Linux kernel for data. The SUSE version of Zp was even considered standard for some time. The main advantages of reiser compared to ext3 are higher speed and placement efficiency when working with small files (and in a file system, as a rule, most files are small). Over time, however, the development of reisefers stopped. It has long been announced that version 4 will be released, which is still not ready, and support for version 3 has ceased. About xfs - the xfs file system was originally developed for SGI workstations running on the IRIX operating system. Xfs is especially good for working with large files, and is particularly ideal for working with streaming video. The system supports quotas and extended attributes (ACLs).
jfs

jfs - a66peBHaTypaJFS stands for "Journaled File System". It was originally developed for IBM and then adapted for Linux. Jfs never enjoyed much recognition on Linux and currently languishes in a miserable existence, inferior to other file systems.
brtfs

brtfs - If it is the will of the leading kernel developers, the brtfs file system in Linux has a bright future. This system was developed from scratch at Oracle. It includes support for device-mapper and RAID. Brtfs is most similar to the ZFS system developed by Sun. Its most interesting features include on-the-fly file system checking, as well as support for SSDs (solid-state drives are hard drives powered by flash memory). Unfortunately, work on brtfs will not be completed in the foreseeable future. Fedora, starting from version 11, provides the ability to install brtfs, but I recommend using it only for file system developers!
There is no "fastest" or "best" file system - the assessment depends on what you intend to use the system for. Beginner Linux users working on a local computer are recommended to work with ext3, and server administrators with ext4. Of course, with ext4 the speed of operation is higher than with ext3, but at the same time, in the ext4 system the situation with data reliability is much worse - you may well lose information if the system suddenly turns off.

If you have installed a second UNIX-like operating system on your computer, then the following file systems will be useful to you when exchanging data (from one OS to another).

sysv - used in SCO, Xenix and Coherent OS.

ufs - used in FreeBSD, NetBSD, NextStep and SunOS. Linux can only read information from such file systems, but cannot make changes to the data. To access segments from BSD, you will additionally need the BSD disklabel extension. A similar extension exists for SunOS partition tables.

ZFS is a relatively new system developed by Sun for Solaris. Because ZFS code is not GPL compliant, it cannot be integrated with the Linux kernel. For this reason, Linux only supports this file system indirectly, through FUSE.
Windows, Mac OS X

The following file systems will be useful when exchanging information with MS DOS, Windows, OS/2 and Macintosh.

vfat - used in Windows 9x/ME. Linux can read information from such partitions and make changes to it. vfat system drivers allow you to work with older MS DOS file systems (8 + 3 characters).

ntfs - the system is used in all modern versions of Windows: otNT and higher. Linux can read and modify its files.

hfs and hfsplus - these file systems are used in Apple computers. Linux can read and modify its files.

Data CDs and DVDs typically use their own file systems.

iso9660 - The file system for CD-ROMs is described in the ISO-9660 standard, which allows only short file names. Long names are supported differently on different operating systems, using a variety of extensions that are incompatible with each other. Linux can run both the Rockridge extension, which is common in UNIX, and the Joliet extension, developed by Microsoft.

udf - this format (universal disk format) appeared and developed as a successor to ISO 9660.

Network file systems

File systems do not have to be on the local disk - they
can connect to a computer and via a network. The Linux kernel supports various network file systems, of which the following are the most commonly used.

smbfs/cifs - help connect Windows or Samba network directories to a directory tree.

nfs is the most important network file system in UNIX.

coda - this system is very similar to NFS. It has many additional features, but it is not very common.

ncpfs - runs on the NetWare kernel protocol; oH is used by Novell Netware.

Virtual file systems

Linux has several file systems that are not designed to store data on the hard drive (or other storage media), but only to exchange information between the kernel and user programs.
devpts - This file system provides access to pseudo terminals (abbreviated as PTY) via /dev/pts/* according to the UNIX-98 specification. (Pseudo-terminals emulate a serial interface. On UNIX/Linux systems, such interfaces are used by terminal emulators such as xterm. Typically, devices such as /dev/ ttypn are used. In contrast, the UNIX-98 specification defines new devices. More details information is reported in the text terminal H0WT0.)
proc and sysfs - the proc file system is used to display service information related to kernel and process management. In addition to this, the sysfs file system builds relationships between the kernel and the hardware. Both file systems are mounted at /proc and /sys.
tmpfs - This system is built on the basis of shared memory according to System V. It is usually mounted at the /dev/shm position and allows efficient exchange of information between two programs. On some distributions (such as Ubuntu), the /var/run and /var/lock directories are also created using the tmpfs file system. The files in these directories are used by some network daemons to store process identification numbers as well as file access information. Thanks to tmpfs, this data is now reflected in RAM. The method guarantees high speed, and also that after the computer is turned off, there will be no files left in the /var/run or /var/lock directories.

usbfs - the usbfs file system, starting with kernel version 2.6 and higher, provides information about connected USB devices. It is usually integrated into the proc file system. About USB device support in Linux.

Other file systems

auto - in fact, there is no file system under that name. However, the word auto can be used in /etc/fstab or with the mount command to specify the file system. In this case, Linux will try to recognize the file system on its own. This method works with most major file systems.
autofs, autofs4

autofs, autofs4 are also not file systems, but kernel extensions that automatically perform mount command for selected file systems. If a file system is not used for some time, the umount command is automatically run on it. This method is convenient primarily in cases where only a few of many NFS directories are actively used at the same time.

To perform such operations, the /etc/init.d/ autofs script automatically executes the automount program when the system starts. It is configured using the /etc/auto.master file. The corresponding programs are automatically installed, for example, in Red Hat and Fedora. In any case, autofs is only activated after configuring /etc/auto.master or /etc/auto.misc.
cramfs and squashfs

cramfs and squashfs - Cram and Squash file systems are read-only. They are used to "pack" as many zipped files as possible into flash memory or ROM (read-only memory).

fuse - FUSE stands for Filesystem in Userspace and allows filesystem drivers to be developed and used outside the kernel. Therefore, FUSE is always used with an external file system driver. FUSE works, in particular, with the NTFS driver ntfs-3g.

gfs and ocfs - Global File System and Cluster File System from Oracle (Oracle Cluster File System) allow you to build giant network file systems that can be accessed in parallel by many computers at the same time.

jffs and yaffs - Journaling Flash File System and Yet Another Flash File System are specifically optimized for working with solid-state drives and flash media. Using special algorithms, they try to use all memory cells evenly (wear leveling technology) to avoid premature system failure.
loop

loop - used to work with pseudo devices. A loopback device is an adapter that can access a regular file as a block device. Thanks to it, you can place any file system in any file, and then connect it to the directory tree using mount. The kernel function responsible for this - pseudo-device support - is implemented in the loop module.

There are a variety of uses for pseudodevices. In particular, they can be used when creating Initial RAM disks for GRUB or LILO, when implementing encrypted file systems, or testing ISO images for CDs.

Storage media file systems

File systems
ISO 9660
Joliet ISO 9660 file system extension.
Rock Ridge (RRIP, IEEE P1282) – an ISO 9660 file system extension designed to store file attributes used in POSIX operating systems
Amiga Rock Ridge Extensions
El Torito
Apple ISO9660 Extensions
HFS, HFS+
Universal Disk Format specification of a file system format independent of the operating system for storing files on optical media. UDF is an implementation of the ISO/IEC 13346 standard
Mount Rainier

File Linux system- this is most often ext4. It is journaled and allows you to conveniently work with data when solving the vast majority of problems. However, there are others. The main types of file systems and principles of working with them will be discussed within the framework of this material.

Types of Linux file systems and their features

Distinctive features are the speed of working with files, security and parameters (such as block size) that exist by default and are set when creating the FS. Perhaps the most important feature is the presence of a magazine. The system log records data or metadata(headers only) from which information can be restored in case of failure.

A file system can be created on any device: on a disk or system partition.

EXT2 file system

EXT2 is currently an outdated file system that is practically not used in modern installations. The main disadvantage is the lack of logging, which, accordingly, makes it impossible to restore data in the event of a failure. Still used on portable storage media such as USB. A magazine is not required for them, since it takes up a certain space.

It also guarantees maximum operating speed.

for EXT2 maximum file size -2 TB

EXT3 file system

Superseded EXT2, the main feature is the appearance of the magazine, is fully backward compatible with EXT2 (EXT2 can be freely converted to EXT3). Nowadays it is also rare; EXT4 is almost always used.

Journal - a special area in memory in which information about all changes is recorded

for EXT3 maximum file size -2 TB
maximum size of all files is 32 TB
each directory can have up to 32,000 subdirectories

When journaling, there are three options (specified when creating the file system):

journal – metadata, as well as the information itself, into the journal
ordered – default option, only metadata is saved even after writing to disk
writeback – only metadata is also saved, you can choose to save it before or after writing to disk

EXT4 file system

The modern version of the extended file system, this is the one most often used

maximum file size -2 TB 16 TB
The maximum size of all files is 1 EB (exabyte). 1 EB = 1024 PB (petabyte). 1 PB = 1024 TB (terabyte).
each directory can have up to 64,000 subdirectories

In EXT4, logging can be turned off by setting the option data when mounted in off

EXT as the main Linux file system and operating practice

The file system is created with the mk2fs command

The required logging option is specified during mounting, for example:

mount /dev/vdc /mnt/1 -t ext3 -o data=journal

Converting from EXT2 E to XT3

ReiserFS

ReiserFS (and the modern implementation of Reiser4 with SELinux support) has good performance and is very productive - especially when working with large numbers of small files. ReiserFS does not allocate inodes for each small file but processes them together, and ReiserFS also uses a journal with several options available. Currently, the file system is supported by developers from Russia.

You can create an FS for a device with the command

XFS

XFS is a journaling file system. Uses RAM to store information, so data loss is possible - for example, when the power goes out.

To use XFS on Ubuntu you will need to install packages xfsprogs And xfsdump

vfat

The Linux file system also exists in the Windows environment. It is used when you need to organize shared access to certain disks and partitions of clients with different operating systems. In other cases, it is not recommended to use it as difficulties may arise when working in Linux.

(Second Extended File System).

· History of the development of Linux file systems

· Disk partition structure in ext2fs

·

· Catalogs

· Device files

· · EXT2fs library

· EXT2fs system tools

· Performance calculation

Math faculty

Software program

2nd year 5th gr.

Chichirov Andrey

False system EXT2fs (Second Extended File System).

History of the development of Linux file systems

The first versions of Linux were developed based on the Minix operating system. It would be easier to share the disks between the two systems than to develop a new file system, so Linus Torvalds decided to introduce Linux support for the Minix file system. At that time, this file system was a fairly efficient software product with a relatively small number of errors.

However, the limitations associated with the structure of the Minix file system were quite high, so they began to think about developing a new file system for Linux.

To simplify the implementation of the new file system into the Linux kernel, a virtual file system (VFS) was developed. VFS was originally written by Chris Provenzano and then rewritten by Linus Torvalds before being integrated into the kernel.

After installing VFS into the kernel, a new file system, EXTfs (Extended File System), was developed in April 1992 and added to Linux version 0.96c. In the new file system, two significant limitations of the Minix system were removed: its maximum size could reach 2 gigabytes, and the maximum file name length could be 255 characters. This was an improvement over the Minix file system, although some problems were still present. There was no support for shared access, modification of the index descriptor, and modification of file change time cells. This file system used linked lists to operate on free blocks and inodes, which greatly affected system performance: over time, the lists became unordered and unsorted, leading to fragmentation of the file system.

The solution to these problems was the release in January 1993 of alpha versions of two new file systems: Xia and EXT2fs (Second Extended File System). For the most part, the Xia file system was based on Minix, with a few new features added. This was mainly the ability to work with long file names, support for larger disk partitions, and support for three file change time cells. On the other hand, EXT2fs was based on EXTfs with many improvements and additions. It also had opportunities for future development.

When these two file systems were released, they were functionally approximately equal. The Xia system was more reliable than the EXT2fs by minimizing it. As they became more widely used, bugs in the EXT2fs system were discovered and a large number of new features and improvements were added. The EXT2fs file system is now very reliable and has become the de facto Linux file system standard.

The following table provides general information about the functionality provided by various file systems.

	Minix FS	Ext FS	Ext2FS	Xia FS
Maximum file system size
Maximum file length
Maximum file name length
Support for three file change time cells
Expandability
Resizable block size
Information protection

If necessary, the length of the file name in Ext 2 can be increased to 1012.

EXT2fs reserves a certain number of blocks for the root user. Typically this is 5% of the total, which allows the system administrator to avoid running out of hard disk space when it is filled with other users' processes.

Disk partition structure in ext2fs

Hard drive manufacturers typically ship their products low-level formatted. As far as I know, this means that the entire disk space is divided into “sectors” of 512 bytes in size using special labels. Such a disk (or disk partition) must be prepared for use on 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 consists of creating a certain logical structure in a disk partition. This structure is constructed as follows. First, a boot area is allocated on the disk. The boot area is created on any file system. On the primary partition, it contains a boot record - a piece of code that initiates the process of loading the operating system at startup. This area is not used on other partitions. The rest of the disk space is divided into blocks. A block can be 1, 2, or 4 kilobytes in size. A block is an addressable unit of disk space. Files are allocated in blocks, so there are trade-offs when choosing the block size. Big size block, as a rule, reduces the number of disk accesses when reading or writing a file, but it increases the proportion of wasted space, especially when there are a large number of small files.

Blocks in their area are combined into groups of blocks. Groups of blocks in a file system and blocks within a group are numbered sequentially, starting with 1. The first block on a disk is numbered 1 and belongs to group number 1. The total number of blocks on a disk (in a disk partition) is a divisor of the disk's capacity, expressed in sectors. And the number of block groups does not have to divide the number of blocks, because the last block group may not be complete. The beginning of each group of blocks has an address, which 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 table.

The structure of a disk partition group of blocks in ext2fs

The first element of this structure (superblock) is the same for all groups, and all the rest are individual for each group. The superblock is stored in the first block of each block group (except for group 1, which has a boot record in the first block). Superblock is the starting point of the file system. It is 1024 bytes in size and Always located at offset 1024 bytes from the beginning of the file system. The presence of multiple copies of a superblock is explained by the extreme importance of this element of the file system. Superblock duplicates are used when recovering a file system after failures.

The information stored in the superblock is used to organize access to the rest of the data on the disk. The superblock determines the size of the file system, the maximum number of files in the partition, the amount of free space, and contains information about where to look for unallocated areas. When the OS starts, the superblock is read into memory and all changes to the file system are first reflected in a copy of the superblock located in the OS and are written to disk only periodically. This improves system performance because many users and processes are constantly updating files. On the other hand, when the system is turned off, the superblock must be written to disk, which does not allow turning off the computer simple shutdown nutrition. Otherwise, the next time you boot, the information recorded in the superblock will not correspond to the real state of the file system.

The superblock has the following structure

Field name	Type	A comment
s_inodes_count	ULONG	Number of inodes 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	Free block counter
s_free_inodes_count	ULONG	Free inode counter
s_first_data_block	ULONG	The first block that contains data. Depending on the block size, this field may be 0 or 1.
s_log_block_size	ULONG	Logical block size indicator: 0 = 1 KB; 1 = 2 KB; 2 = 4 KB.
s_log_frag_size	LONG	Fragment size indicator (it seems the fragment concept is not currently used)
s_blocks_per_group	ULONG	Number of blocks in each block group
s_frags_per_group	ULONG	Number of fragments in each block group
s_inodes_per_group	ULONG	Number of inodes in each block group
s_mtime	ULONG	The time the file system was last mounted.
s_wtime	ULONG	Time when the file system was last written to
s_mnt_count	USHORT	Counter of the number of file system mounts. If this counter reaches the value specified in the next field (s_max_mnt_count), the file system must be checked (this is done on restart) and the counter is reset to zero.
s_max_mnt_count	SHORT	A number that determines how many times the file system can be mounted
s_magic	USHORT	"Magic number" (0xEF53) indicating that the file system is of type ex2fs
s_state	USHORT	Flags indicating the current state of the file system (is it clean, etc.)
s_errors	USHORT	Flags that specify procedures for processing error messages (what to do if errors are found).
s_pad	USHORT	Filling
s_lastcheck	ULONG	Time of last file system check
s_checkinterval	ULONG	Maximum time period between file system checks
s_creator_os	ULONG	An indication of the type of OS in which the file system was created
s_rev_level	ULONG	Version (revision level) of the file system.
s_reserved	ULONG	Padding up to 1024 bytes

Following the superblock is a description of the group of blocks (Group Descriptors). This description is an array with the following structure.

Field name	Type	Purpose
bg_block_bitmap	ULONG	Address of the block containing the block bitmap of this group
bg_inode_bitmap	ULONG	Address of the block containing the inode bitmap of this group
bg_inode_table	ULONG	Address of the block containing the 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	Number of free inodes in this group
bg_used_dirs_count	USHORT	The number of inodes in a given group that are directories
bg_pad	USHORT	Filling
bg_reserved	ULONG	Filling

The size of the block group description can be calculated as (block_group_size_in_ext2 * number_of_groups) / block_size(round if necessary).

The information stored in the group description is used to locate the block and inode bitmaps, as well as the inode table. Don't forget that blocks and groups of blocks are numbered starting from 1.

A block bitmap is a structure in which each bit indicates whether the corresponding block is allocated to a file. If the bit is 1, then the block is busy. This map is used to search for free blocks in cases where it is necessary to allocate space for a file. The block bitmap occupies a number of blocks equal to (number_of_blocks_in_group / 8) / block_size(round if necessary).

The inode bitmap performs a similar function to the inode table: it shows which inodes are in use.

The next area in the block group structure is used to store the file inode table. The structure of the inode itself is discussed in more detail in the next subsection.

Well, and finally, all the remaining space in the group of blocks is allocated for storing the actual files.

File system Ext 2 is characterized by:

hierarchical structure,
coordinated processing of data sets,
dynamic file extension,
protection of information in files,
treating peripheral devices (such as terminals and tape devices) as files.

Internal file representation

Each file in the Ext 2 system has a unique index. The index contains the information needed by any process to access the file. Processes access files using a well-defined set of system calls and identifying the file with a string of characters that acts as a qualified file name. Each compound name uniquely identifies a file, so the system kernel converts this name into a file index. The index includes a table of addresses where file information is located on disk. Since each block on a disk is addressed by its own number, this table stores a collection of disk block numbers. To increase flexibility, the kernel appends a file one block at a time, allowing the file's information to be scattered throughout the file system. But this layout complicates the task of searching for data. The address table contains a list of block numbers containing information belonging to a file, but simple calculations show that a linear list of file blocks in an index is difficult to manage. In order for a small index structure to allow working with large files, the table of disk block addresses is brought into line with the structure shown in Figure 1

Most files in an Ext 2 system are no larger than 10 KB or even 1 KB! Because 10 KB of a file are located in direct addressing blocks, most of the data stored in files can be accessed in a single disk access. Therefore, unlike accessing large files, working with standard-sized files is fast.

File inodes

Each file on disk is associated with one and only one file inode, which is identified by its sequential number - the file index. This means that the number of files that can be created on a file system is limited by the number of inodes, which is either explicitly specified when the file system is created or calculated based on the physical size of the disk partition. Inodes exist on disk in static form and the kernel reads them into memory before working with them.

The file inode has the following structure:

Field name	Type	Description
I_mode	USHORT	The 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	Time of the last access to the file (Access time).
I_ctime	ULONG	File creation time.
I_mtime	ULONG	Time of the last modification of the file.
I_dtime	ULONG	File deletion time.
I_gid	USHORT	Group ID (GID).
I_links_count	USHORT	Links count.
I_blocks	ULONG	The number of blocks occupied by the file.
I_flags	ULONG	File flags (File flags)
I_reserved1	ULONG	Reserved for OS
I_block	ULONG	Pointers to blocks in which file data is written (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	Directory ACL
I_faddr	ULONG	Fragment address
I_frag	UCHAR	Fragment number
I_fsize	UCHAR	Fragment size
I_pad1	USHORT	Filling
I_reserved2	ULONG	Reserved

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

Identifier	Meaning	Purpose of the flag (field)
S_IFMT	F000	File type mask
S_IFSOCK	A000	Domain socket
S_IFLNK	C000
S_IFREG	8000	Regular file
S_IFBLK	6000	Block-oriented device
S_IFDIR	4000	Catalog
S_IFCHR	2000	Byte-oriented (character) device
S_IFIFO	1000	Named pipe (fifo)

S_ISUID	0800	SUID - change owner bit
S_ISGID	0400	SGID - group change bit
S_ISVTX	0200	Task saving bit (sticky bit)

S_IRWXU	01C0	File owner rights mask
S_IRUSR	0100	Right to read
S_IWUSR	0080	Write right
S_IXUSR	0040	Right to execute

S_IRWXG	0038	Group rights mask
S_IRGRP	0020	Right to read
S_IWGRP	0010	Write right
S_IXGRP	0008	Right to execute

S_IRWXO	0007	Mask of rights of other users
S_IROTH	0004	Right to read
S_IWOTH	0002	Write right
S_IXOTH	0001	Right to execute

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

Identifier	Meaning	Description
EXT2_BAD_INO		An inode that lists the addresses of bad blocks on the disk (Bad blocks inode)
EXT2_ROOT_INO		Inode of the file system root directory (Root inode)
EXT2_ACL_IDX_INO		ACL inode
EXT2_ACL_DATA_INO		ACL inode
EXT2_BOOT_LOADER_INO		Boot loader inode
EXT2_UNDEL_DIR_INO		Undelete directory inode
EXT2_FIRST_INO		First unreserved inode

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

Field name	Type	Description
Inode	ULONG	file inode number
rec_len	USHORT	Length of this entry
name_len	USHORT	File name length
Name	CHAR	File name

An individual directory entry cannot cross a block boundary (that is, it must be located entirely within a single block). Therefore, if the next record does not fit entirely in a given block, it is transferred to the next block, and the previous record continues so that it fills the block to the end.

Figure 1 Direct and indirect addressing blocks in the index

Figure 2 File size in bytes with a block size of 1 KB

Figure 3. Example of a disk index

Figure 3 shows the disk index of a certain file. This index belongs to a regular file whose owner is "mjb" and whose size 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 only allowed to read or execute the file, but not write data to it. The file was last read on October 23, 1984 at 1:45 p.m., and last written to on October 22, 1984 at 10:30 a.m. The index was last modified on October 23, 1984 at 1:30 p.m., although no information was written to the file at that time. The kernel encodes all the above data in an index. Note the difference in writing to disk the contents of the index and the contents of the file. The contents of a file change only when a write is made to the file. The contents of the index change both when the contents of the file change and when the file owner, access rights, and pointer set change. Changing the contents of a file automatically causes the index to be adjusted, but adjusting the index does not mean changing the contents of the file.

Catalogs

Directories are the files from which the hierarchical structure of the file system is built; they play an important role in turning the file name into an index number. A directory is a file whose contents are a set of entries consisting of the index number and file name included in the directory. A qualified name is a string of characters terminated by a null character and separated by a slash ("/") into multiple components. Each component except the last must be the name of a directory, but the last component can be the name of a file that is not a directory. In UNIX version V, the length of each component is limited to 14 characters; Thus, together with the 2 bytes allocated for the index number, the size of the directory entry is 16 bytes.

Byte offset inside the directory	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 /etc directory format

Figure 4 shows the format of the "etc" directory. Each directory contains files whose names are indicated by a dot and two dots ("." and "..") and whose index numbers coincide with the index numbers of the given directory and the parent directory, respectively. Index number for file "." in the directory "/etc" has an address at offset 0 and a value of 83. The inode number for the file ".." has an address at offset 16 from the start of the directory and a value of 2. Entries in the directory can be empty, but the inode number is 0. For example , the entry at address 224 in the "/etc" directory is empty, despite the fact that it once contained an entry point for a file called "crash". The mkfs program initializes the file system so that the inode numbers for files are "." and ".." in the root directory are the same as the root index number of the file system.

The kernel stores data in a directory just as it does in a regular file type, using an index structure and blocks with direct and indirect addressing levels. Processes can read data from directories in the same way they read regular files, but exclusive write access to the directory is reserved by the kernel, ensuring that the directory structure is correct. Directory permissions have the following meaning: read permission gives processes the ability to read data from the directory; write permission allows a process to create new entries in a directory or remove old ones (using the creat, mknod, link, and unlink system operations), thereby changing the contents of the directory; The execute right allows a process to search a directory by file name (since "executing" a directory is meaningless).

When a process uses a file path, the kernel looks in the directories for the corresponding inode number. After the file name has been converted to an inode number, the inode is placed in memory and then used in subsequent requests.

The concept of Unix file systems includes the concept of a link. A single inode can be associated with multiple filenames. The descriptor contains a field that stores the number with which the file is associated. Adding a link consists of creating a directory entry where the inode number points to another inode, and incrementing the link counter in the inode. When a link is removed, the kernel decrements the link counter and removes the handle if the counter becomes zero.

Such links are called hard links and can only be used within one file system (you cannot create a link for a file from another file system). Moreover, a hard link can only point to a file (a hard link to a directory can cause a loop in the file system).

On most Unix systems there is another type of link. These links, containing only the file name, are called symbolic. When the kernel processes such links, when converting the file path into an inode, the kernel replaces the link name with the contents of the inode (that is, the destination file name) and reinterprets the file path. Since a symbolic link does not point to an inode, it is possible to create links to files located on another file system. These links can point to any type of file, even non-existent ones. Symbolic links are widely used because they do not have the same restrictions that hard links have. However, they take up some space on the disk where the inode and data blocks are located. Their use may result in some delays in converting the file path to an inode, due to the fact that the kernel must reinterpret the file path when processing a symlink.

Device files

In Unix-like operating systems, devices are accessed through special files. Such a file does not take up space in the file system. It is only an access point to the device driver.

There are two types of device files: character and block. When using a character type, it is possible to exchange data with the device only in character mode, while block-type device files allow only blocks to be exchanged using a buffer. When an I/O request is made to a device file, the request is forwarded to the appropriate device driver. Each such file has a major number that identifies the type of device, and a minor number that identifies the device itself.

Additional features of EXT2fs

In addition to standard Unix features, EXT2fs provides some additional features not typically supported by Unix file systems.

File attributes allow you to change how the kernel reacts when working with sets of files. You can set attributes on a file or directory. In the second case, files created in this directory inherit these attributes.

During system mounting, some features related to file attributes may be set. The mount option allows the administrator to choose how files are created. In a BSD-specific file system, files are created with the same group ID as the parent directory. The features of System V are somewhat more complex. If a directory has its setgid bit set, then created files inherit the group ID of that directory, and subdirectories inherit the group ID and setgid bit. Otherwise, files and directories are created with the primary group ID of the calling process.

The EXT2fs system can use synchronous data modification similar to BSD system. The mount option allows the administrator to specify that all data (inodes, bit blocks, indirect blocks, and directory blocks) be written to disk synchronously when they are modified. This can be used to achieve high data recording capacity, but also results in poor performance. In reality, this function is not usually used because, in addition to degrading performance, it can lead to the loss of user data that is not flagged when checking the file system.

EXT2fs allows you to select the logical block size when creating a file system. It can be 1024, 2048 or 4096 bytes in size. Using larger blocks results in faster I/O operations (since fewer disk requests are made), and therefore less head movement. On the other hand, using large blocks leads to wasted disk space. Typically, the last block of a file is not completely used for storing information, so as the block size increases, the amount of wasted disk space increases.

EXT2fs allows you to use accelerated symbolic links. When using such links, file system data blocks are not used. The destination file name is not stored in the data block, but in the inode itself. This structure allows you to save disk space and speed up the processing of symbolic links. Of course, the space reserved for a handle is limited, so not every link can be represented as an accelerated link. The maximum length of a file name in an accelerated link is 60 characters. In the near future it is planned to expand this scheme for small files.

EXT2fs monitors the state of the file system. The kernel uses a separate field in the superblock to indicate the state of the file system. If the file system is mounted in read/write mode, then its state is set to "Not Clean". If it is dismantled or remounted in read-only mode, then its state is set to “Clean”. During system boot and file system status checks, this information is used to determine whether a file system check is necessary. The kernel also places some errors in this field. When the kernel detects a mismatch, the file system is marked as "Erroneous". The file system checker tests this information to check the system, even if its status is actually Clean.

Ignoring file system testing for a long time can sometimes lead to some difficulties, so EXT2fs includes two methods for regularly checking the system. The superblock contains the system mount counter. This counter is incremented each time the system is mounted in read/write mode. If its value reaches the maximum (it is also stored in the superblock), then the file system test program starts checking it, even if its state is "Clean". The last check time and the maximum interval between checks are also stored in the superblock. When the maximum interval between scans is reached, the state of the file system is ignored and its scan is started.

The EXT2fs system contains tools for configuring it. The tune2fs program can be used to change:

actions when an error is detected. When the kernel detects a discrepancy, the file system is marked as "Erroneous" and one of the following three actions can be performed: continue execution, remount the file system in read-only mode to avoid damage, or reboot the system to check the file system.
maximum mount value.
maximum interval between checks.
number of logical blocks reserved for the root user.

Options specified at mount can also be used to change what the kernel does when it detects an error.

Using attributes allows users to delete sensitive files. When such a file is deleted, random information is written to the blocks that were previously used to place this file. This prevents outsiders from gaining access to the previous contents of this file using a disk editor.

New file types have recently been added to the EXT2fs system, taken from the 4.4 BSD file system. Files of the first type can be used for reading only: no one has the right to change or delete them. This can be used to protect important configuration files. Another type of file is a file that can be opened in write mode, and data can only be appended to the end of the file. Files of this type also cannot be deleted or renamed. They can be used as log files, which can only grow in size.

Performance optimization

The EXT2fs system contains many features that optimize its performance, which leads to increased speed of information exchange when reading and writing files.

EXT2fs actively uses the disk buffer. When a block needs to be read, the kernel issues an I/O operation request to several adjacent blocks. Thus, the kernel tries to make sure that the next block to be read has already been loaded into the disk buffer. Such operations are usually performed when reading files sequentially.

The EXT2fs system also contains a large number of optimizations for information placement. Block groups are used to group together corresponding inodes and data blocks. The kernel always tries to place the data blocks of one file in the same group, as well as its descriptor. This is intended to reduce the movement of the drive heads when reading the descriptor and its corresponding data blocks.

When writing data to a file, EXT2fs pre-allocates up to 8 contiguous blocks when allocating a new block. This method allows you to achieve high performance under heavy system load. This also allows files to be placed in contiguous blocks, which speeds up their subsequent reading.

EXT2fs library

To simplify the use of EXT2fs resources and the operation of control structures of this file system, the libext2fs library was developed. This library contains functions that can be used to define and modify EXT2 file system data by directly accessing the physical device.

Most EXT2fs utilities (mke2fs, e2fsck, tune2fs, dumpe2fs, debugfs, etc.) use this library. This greatly simplifies modification of these utilities, since any changes to introduce additional capabilities into the EXT2fs file system must be made only in the EXT2fs library.

Since the interface of the EXT2fs library is quite broad and abstract, programs that require direct access to the file system can be easily written with its help. For example, the EXT2fs library was used during the transfer of the 4.4 BSD dump and the restoration of some utilities. Very few changes were required to adapt these tools to Linux (we had to replace several filesystem-interacting functions with calls to the EXT2fs library).

The EXT2fs library provides access to the operations of several classes. The first class is operations related to the file system. Any program can open or close a file system, read or write a block of bits, or create a new file system on disk. There are also functions for manipulating a list of file system bad blocks.

The second class of operations works with directories. A program using the EXT2fs library can create or expand a directory, as well as add or delete entries in a directory. There are functions for both determining the path to a file using an inode and determining the path to a file using a specified descriptor.

The last class of operations operates on index handles. It is possible to read the table of descriptors, read or write a descriptor, and view all blocks of the specified descriptor. It is possible to use functions for placing and releasing blocks and descriptors.

EXT2fs system tools

Powerful controls have been developed for the EXT2fs system. These tools are used to create, modify, and correct any inconsistencies in EXT2fs file systems. The mke2fs program is used to mount a disk partition containing an empty EXT2fs file system.

The tune2fs program can be used to configure file system parameters. With its help, you can change the response to errors, the maximum number of system mounts, the maximum interval between system checks and the number of logical blocks reserved for the root user.

Perhaps the most interesting tool is the file system checker. E2fsck is designed to eliminate inconsistencies in the file system after an inaccurate shutdown of the entire system. The initial version of the e2fsck program is based on the Linus Torvald fsck program for the Minix file system. However, the current version of the program is rewritten using the EXT2fs library and is faster and can correct more errors in the system when checking it, compared to the original version.

The e2fsck program was designed to run at maximum speed. Since file system check programs lead to disk loading, the e2fsck algorithms should be optimized so that file system structures are accessed much less frequently. And, in addition, the order of checking inodes and directories would be performed by block number to reduce the time it takes to move disk drive heads.

In the first pass, e2fsck runs through all inodes on the file system and examines each inode as a separate system element. Thus, other file system objects are not checked during this testing. One of the purposes of such checks is to check the existence of the type of the file being checked, as well as the correspondence of all blocks in the descriptor with blocks with existing numbers. The first pass checks the bit maps indicating the use of blocks and descriptors.

If e2fsck finds data blocks whose numbers are contained in more than one descriptor, then passes 1B through 1D are run to resolve the discrepancy, either by increasing the blocks to be shared or by removing one or more descriptors.

The first pass takes the most time, since all inodes must be read into memory and checked. To reduce the time of I/O operations in subsequent passes, all necessary information remains in the buffer. A characteristic feature of this scheme is the search for all directory blocks of the file system. To obtain this information, in the second pass the descriptor structures of all directories in the file system are read again.

In the second pass, directories are checked as separate elements of the file system. Each directory block is checked separately, without reference to other directory blocks. This allows e2fsck to sort all directory blocks by block number and check them in ascending order, thus reducing disk access time. Directory blocks are tested to ensure that their entries are valid and that they contain references to handles with existing numbers (as determined in the first pass).

For the first directory block in each directory descriptor, the existence of "." entries is checked. and "..", and that the descriptor number for the entry "." matches the current directory. (The descriptor number for the ".." entry is not tested until the third pass.)

During the second pass, information corresponding to the parent directory is stored in a buffer.

It should be noted that by the end of the second pass, almost all I/O operations on the disk are completed. All information required for the third, fourth and fifth passes is contained in memory, however, the remaining passes load the processor and take up less than 5-10% of the total e2fsck execution time.

In the third pass, directory connections are checked. E2fsck checks the paths of each directory towards the root using the information obtained during the second pass. Here the ".." entry for each directory is checked. All directories identified after checking and not having a connection with the root directory are placed in the /lost+found directory.

In the four -time, the E2FSCK reaches the references for each index deskiptop by applying all the deskiptes and the interpretation of references (this infopation is in the afternoon) with the indigenous meters, the values of which were calculated in the rest of the second and the second moves. All undeleted files with a reference count of zero are also placed in the /lost+found directory.

Finally, in the fifth pass, e2fsck checks that all file system information matches. Here, the bitmaps of blocks and descriptors that were obtained in previous passes are compared with the actual values and, if necessary, the information on disk is adjusted accordingly.

Another useful tool is the file system debugger. Debugfs is a powerful program that allows you to determine and set the state of a file system. Essentially, it is an interactive interface to the EXT2fs library, that is, it translates typed commands into calls to library functions.

Debugfs can be used to determine the internal structure of a filesystem, manually repair a damaged system, or create conditional tests for e2fsck. Unfortunately, this program can damage the file system if you don't know how to use it. Using this tool, you can simply destroy the file system. Therefore, debugfs opens the file system in read-only mode by default. To access in read/write mode, specify the -w option.

Performance calculation

The Bonnie test results can be seen from the following table:

	Character-by-character recording (Kb/s)	Block recording (Kb/s)	Dubbing (Kb/s)	Character-by-character reading (Kb/s)	Block Read (Kb/s)
BSD Async
BSD Sync
Ext2fs		1237			1033
Xia fs

The results are quite good for block I/O: the EXT2fs system outperforms other systems in terms of performance. This is due to the optimizations included in the placement procedures. Recording also happens quite quickly, due to the fact that it is done in group mode. The high read speed is due to the fact that the blocks have been allocated to the file, so the drive heads do not move between two reads and the pre-read optimization is fully operational.

On the other hand, the FreeBSD system has higher performance for symbolic I/O. This may be due to the fact that FreeBSD and Linux use different procedures for the corresponding C libraries. In addition, FreeBSD most likely has a more optimized symbolic reading library and therefore performance is slightly better here.

Andrew test results

Andrew's test results can be seen from the following table:

	Passage 1 Creation	Pass 2 Copy	Passage 3 Status check	Pass 4 Byte-by-byte check	Passage 5 Compilation
	2203	7391	6319	17466	75314
BSD Sync	2330	7732	6317	17499	75681
Ext2fs

The results of the first two passes show that Linux wins with asynchronous data exchange. When creating directories and files, the BSD system writes directory handles and directory entries synchronously. There is speculation that asynchronous support for FreeBSD has not yet been fully implemented.

In the third pass, the values for Linux and BSD are very similar. While BSD performs better, adding a filename buffer to the Linux VFS eliminates this problem.

In the fourth and fifth passes, Linux is faster than FreeBSD, mainly due to the use of unified buffer management. The buffer size can grow as needed and take up more memory than FreeBSD, which uses a fixed size. A comparison of the results of the EXT2fs and Xia fs systems shows that the optimizations included in EXT2fs are actually used: the difference in the performance of these systems is about 5-10%.

Conclusion

The EXT2 file system is the most widely used among Linux users. It provides standard Unix features and additional features. Moreover, thanks to the optimization included in the kernel, it shows excellent performance results.

The EXT2fs system includes features that allow you to add new capabilities. Some people are working on developing extensions to the real file system: Posix ACL, recovery deleted files and file compression in real time.

First, the EXT2fs system was integrated into the Linux kernel, and now it is actively being ported to other operating systems. EXT2fs is also an important component of the Masix operating system, which is currently being developed by one of the authors.

Popular in the category: