File systems ext2, ext3, XFS, ReiserFS, NTFS
File system- this is an order that determines the way the organization, storage and naming of data on any electronic storage media in computers.
The variety of file systems is explained by the fact that each was invented for its specific task package. Some write small files very quickly (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 in terms of security, others in terms of write / read speed. Each file system has its pros, cons, vulnerabilities and distinctive features.
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-2001 it was the main file system linux.
The advantage is the high read / write speed.
The main disadvantage of the system ext2 is that it is not journaled, but it is thanks to this that it has great performance ( logging- this is a logging 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, used to this day in distributions linux. Was born as an improved ext2.
The advantage of this system is that it is journaled, that is, its reliability increases many times 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 kernel linux as a file system in 2002 to the entire family of distributions linux, currently used as "native" in the distribution red hat.
The advantage is the presence of metadata logging, high stability of work, the distribution of I / O streams into groups is supported, high read / write speed, 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 size of the partition cannot be reduced, the processing of metadata is not so fast, 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. Used only on operating systems linux. It was the first journaling 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 family ext4), supports logging.
The disadvantage is that its development has slowed down noticeably due to the arrest of the head 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. It is widely used in various operating systems, as well as in various storage media.
The advantage is the built-in ability to restrict access to data for different users, as well as set limits on the maximum amount of disk space, the use of a journaling system, and high speed reading / writing small files.
The disadvantage is that for stable operation, not a small PC RAM is needed, it works slowly with large files, the length of the file path is limited (32,767 Unicode characters).
In such a simple way, we figured out the "file systems ext2, ext3, XFS, ReiserFS, NTFS«!
How in Windows environment make it possible to access a disk partition or removable media with file systems Ext2/3/4
?
If, for example, there is also a second system on the computer linux. And it is necessary to work with its data from the environment Windows. Or another example - when inside Windows are mounted virtual disks with installed on virtual machines systems linux or Android. With Ext2/3/ 4
Windows does not work natively, it needs third-party tools for this. What are these funds? Let's consider those below.
***
The first three means will make it possible only to read information devices with Ext2/3/4. The last solution will allow both reading and writing data. All of the tools below are free.
1. DiskInternals Linux Reader
A simple program is a primitive file manager, made like a regular 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, 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 after installing a special plugin into 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.
We launch (important) on behalf of the administrator. We go to the section. We press .
Here, along with other disk partitions and media, the one with Ext2/3/4 .
The data is copied to the traditional way - by pressing F5 on the second panel.
3. Plugin for Total Commander ext4tc
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, start the installation.
We launch (important) on behalf of the administrator. Click . We go into.
If you need to copy data, use the usual method with the F5 key.
4. Driver support Ext2Fsd
Program Ext2Fsd is a driver Ext2/3/4, it implements support for these file systems at the level operating system. You can work with disk partitions and drives formatted in these file systems as with regular, supported Windows devices information in the explorer window, or third party programs. The driver allows both reading and writing data.
Downloading the latest current version Ext2Fsd.
During installation, activate (if for long term work) three suggested checkboxes:
1
- Autorun driver with Windows;
2
- Recording support for ext2;
3
- Formatting support for Ext3.
At the pre-finish stage, we activate the option to launch the driver manager window - - with the associated assignment of information to devices with Ext2/3/4 drive letters.
In the window that opened we will see the carrier 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 You can use the context menu called on each of the displayed in the window devices. But just by assigning a drive letter, such a device will not be displayed after restarting Windows, this is a solution for only one session with the computer. 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 settings window and set permanent connection parameters. In the second column you need:
For removable media, activate the checkbox indicated by the number 1 in the screenshot and indicate the drive letter;
For internal disks and partitions, activate the checkbox indicated in the screenshot below by the number 2, and also indicate the drive letter.
We will now describe the most popular Linux disk file system, ext2. The first release of Linux used the MINIX 1 file system, which had short file names and a maximum file size of 64 MB. The MINIX 1 file system was eventually replaced by the first extended file system, ext, which allowed for longer file names and larger file sizes. Due to its low efficiency (in terms of performance), the ext system was replaced by its successor ext2, which is still widely used today.
The disk partition with ext2 contains the file system shown in fig. 10.17 layout. Block 0 is not used by the Linux system and contains the computer's boot code. Following block 0, the disk partition is divided into groups of blocks (ignoring disk cylinder boundaries). Each group is organized as follows.
The first block is the 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 (usually several hundred elements). This is followed by a group descriptor containing information about the location of the bitmaps, the number of free blocks and i-nodes in the group, and the number of directories in the group. This information is important because the ext2 filesystem attempts to distribute directories evenly across the disk.
The two bitmaps keep track of free blocks and free i-nodes (this is also inherited from the MINIX 1 file system and distinguishes it from most UNIX file systems, which use a list for free blocks). The size of each bitmap is one block. With a block size of 1 KB, this scheme limits the block group size to 8192 blocks and 8192 i-nodes. The first number is a real limit, and the second is practically none. With 4 KB blocks, the numbers are four times larger.
Then the i-nodes themselves are located. They are numbered from 1 to some maximum. Each i-node is 128 bytes in size and describes exactly one file. The i-node contains accounting information (including everything returned by the stat call, which simply takes it from the i-node), as well as enough information to locate all the disk blocks that contain the file's data.
The i-nodes are followed by data blocks. All files and directories are stored here. If a file or directory consists of more than one block, then those blocks need not be contiguous on disk. In reality, blocks of a large file are likely to be scattered all over the disk.
The i-nodes corresponding to the directories are scattered across all disk block groups. Ext2 tries to place regular files in the same block group as the parent directory, and data files in the same block as the i-node of the source file (assuming there is enough space there). This idea was borrowed from the Berkeley Fast File System (McKusick et al., 1984). Bitmaps are used to receive quick fixes regarding the selection
places for new file system data.
When new blocks of files are allocated, ext2 also preallocates several (eight) additional blocks for the same file (to minimize file fragmentation due to future writes). This scheme spreads the file system across the disk. It also has good performance (due to its contiguous nature and reduced fragmentation).
To access a file, you must first use one of the Linux system calls (such as open), which requires you to specify the path to the file. This path is parsed and its constituent directories are extracted from it. If a relative path is specified, then the search starts from the current directory of the process, otherwise, from the root directory. In any case, the i-node for the first directory is easy to find: there is a pointer to it in the process descriptor, or (in the case of the root directory) it is stored in a specific block on disk.
The directory allows filenames up to 255 characters long (Figure 10.18). Each directory consists of a number of disk blocks (so that the directory can be written to disk atomically). In a directory, the elements for files and directories are in unsorted order (each element immediately follows the previous one). Elements cannot cross block boundaries, so there is usually some amount of unused bytes at the end of each disk block.
Each directory entry in Fig. 10.18 consists of four fixed-length fields and one variable-length field. The first field is the i-node number, which is 19 for the colossal file, 42 for the voluminous file, and 88 for the bigdir directory. Next comes the rec_len field, which gives the size of the entire directory entry in bytes (possibly with additional padding bytes after the name). This field is needed to find the next entry (in the case where the file name is padded with an unknown number of bytes). In the figure, this field is indicated by an arrow. Then there is a field of type file, directory, etc. The last fixed-length field contains the length of the file name in bytes (8, 10 and 6 for this example). Finally, there is the filename itself, terminated by a null byte and padded to a 32-bit boundary. It may be followed by additional padding bytes.
On fig. 10.18b shows the same directory after the element for voluminous has been removed. All it does in the directory is increase the number in the previous colossal file's entry size field, and the directory entry's bytes for remote file voluminous turn into placeholders for the first record. Subsequently, these bytes can be used for writing when creating a new file.
Since the search in directories is linear, the search for the entry that is at the end big catalog, may take a long time. Therefore, the system maintains a cache of recently accessed directories. The cache is searched by file name, and if it is found, then the expensive linear search is no longer needed. The dentry object is entered into the directory entry cache for each of the path components, and (via its i-node) the directory is searched for subsequent path entries (until the actual i-node of the file is found).
For example, to find a file specified by an absolute path (such as /usr/ast/file), the following steps must be followed. First of all, the system finds the root directory that i-node number 2 usually uses (especially when i-node number 1 is reserved for bad blocks). It places the appropriate entry into the directory entry cache (for future searches of the root directory). It then searches the root directory for the string "usr" to obtain the i-node number for the /usr directory (which is also entered into the directory's item cache). This i-node is then read and disk blocks are extracted from it, so that the /usr directory can be read and searched for the string "ast". Once a matching entry has been found, the i-node number for the /usr/ast directory can be determined from it. Given this i-node number, it can be read and directory blocks found. Finally, we search for "file" and find its i-node number. Thus, using a relative path is not only more convenient for the user, but also reduces the amount of work for the system.
If the file is present, the system retrieves the i-node number and uses it as an index of the i-node table (on disk) to look up the corresponding i-node and read it into memory. This i-node is placed in the i-node table, a kernel data structure that contains all the i-nodes for the currently open files and directories. The i-node element format must contain (at a minimum) all the fields returned by the stat system call for the stat call to work (see Table 10.10). In table. Figure 10-13 shows some of the fields in the i-node structure supported by the Linux file system. The actual i-node structure contains many more fields, since the same structure is used to represent directories, devices, and other special files. The i-node structure also contains fields reserved for future use. History has shown that unused bits don't stay idle for long.
Now let's see how the system reads the file. Remember that a typical library procedure call to run the read system call looks like this:
n = read(fd, buffer, nbytes);
When the kernel takes control, all it can start with are these three parameters and the information in its internal tables (pertaining 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 per open file (up to some maximum number, usually 32 by default).
The idea is to start at this file descriptor and end with the corresponding bnode. Let's look at one possible scheme: put a pointer to a node in a table of file descriptors. Despite the simplicity, this method (unfortunately) does not work. The problem is this. Each file descriptor must have an associated file pointer that specifies the byte in the file where the next read or write operation will begin. Where should this pointer be stored? One option is to place it in the node table. However, this approach will not work if several unrelated processes open the same file at the same time, because each process must have its own pointer.
The second solution is to place a pointer in the file descriptor table. Each process that opens a file has its own position in the file. Unfortunately, this scheme also doesn't work, but the reason for the failure in this case is not so obvious and has to do with the nature of file sharing in the Linux system. Consider shell script 5, which consists of two commands (p1 and p2) to be executed in turn. If the script is called from the command line
then p1 is expected to write its output to file x, and then p2 is also expected to write its output to file x, starting where p1 left off.
When the shell starts p1, file x will be empty at first, so p1 will simply start writing to the file at position 0. However, when p1 is done, some mechanism is needed to ensure that p2 sees the start position not 0 (but this is exactly what happens if the position in the file is stored in the file descriptor table), but the value at which pi stopped.
How this is done is shown in Fig. 10.19. The trick is to introduce a new table - the description table open files(open file description table) - between the file descriptor table and the i-node table and store the file pointer (as well as the read/write bit) in it. In the figure, the parent process is the shell, and the child is first the pi process and then the p2 process. When the shell creates the pi process, its user structure (including the file descriptor table) is an exact copy of the same shell structure, so they both contain pointers to the same open file description table. When the pi process exits, the shell's file descriptor continues to point to the open file description table, which contains the p1 process's position in the file. When the shell now creates the p2 process, the new child process automatically inherits the file position, and neither the new process nor the shell is required to know the current value of that position.
If some extraneous process opens the file, then it will get its own entry in the open file description table with its position in the file, which is exactly what is needed. Thus, the purpose of the open file description table is to allow parent and child processes to share a single pointer in a file, but to allocate personal pointers for foreign processes.
So (returning to the problem of performing a read), we have shown how the position in the file and the i-node are determined. The I-node contains the disk addresses of the first 12 blocks of the file. If the position in the file falls within its first 12 blocks, then the desired block of the file is read and the data is copied to the user. For files longer than 12 blocks, the i-node contains the disk address of a single indirect block (Figure 10.19). This block contains the disk addresses of additional disk blocks. For example, if the block size is 1 KB and the disk address is 4 bytes, then a single indirect block can store up to 256 disk addresses. This scheme allows you to support files up to 268 KB in size.
If you have two operating systems installed, Windows and Linux, then for sure you would like to be contained on partitions of a free operating system directly from under Windows without restarting your computer.
Unfortunately, Linux OS partitions are not supported in Windows. But in vain. It seems to me that this could be a nice gesture from Microsoft.
The essence of the problem lies in the fact that Windows uses the NTFS file system, and Linux has its own way of organizing files, the extended file system, the latest version of which has a serial number 4.
Linux is more friendly to its users than its commercial sister: Linux provides support for the Windows NTFS file system by default. Of course, you will not be able to install Linux on an NTFS partition, but you can read and write data from such a partition.
Ext2 IFS
Ext2 IFS supports Windows NT4.0/2000/XP/2003/Vista/2008 x86 and x64 versions and allows you to view and write to Linux ext2 partitions. The utility installs the ext2fs.sys system driver, which extends the capabilities of Windows and includes full support for ext2 in it: drive letters are assigned to ext2 partitions, and files and folders on them are displayed in the dialogs of all applications, for example, in Explorer.
Ext2 FSD
Ext2 FSD is a free driver for Windows systems(2K/XP/VISTA/7 x86 and x64 versions). Like the previous utility, which is also a driver in its essence, it includes full support for the ext2 file system in Windows.
LTOOLS - a set of utilities command line, which allows you to read and write data to/from Linux ext2, ext3 and ReiserFS partitions (standard Linux file systems) from a DOS or Windows machine.
There is a version of the program with a graphical shell (written in Java) - LTOOLSgui, as well as a version with a graphical shell written in .
Ext2Read
For dessert, as always, the most delicious.
Ext2Read is a file manager utility that allows you to both view and write to ext2/ext3/ext4 partitions. Supports LVM2 and, what distinguishes it from other programs in this review, the ext4 file system. Support for recursive copying of directories is built in.
And here is the second dessert. Initially, it was said that it would be a good move from Microsoft to enable support for Linux partitions in Windows by default.
The gesture was nevertheless made on the 20th anniversary of Linux. See for yourself.
That's all. Thanks for attention. I'm going to fight off the May bugs. There are so many of them this spring. 🙂
File system(English file system) - an order that determines the method of organizing, storing and naming data on information carriers of IT equipment (using portable flash memory cards in portable electronic devices: digital cameras, mobile phones etc. e) and computer technology. It defines the format of the content and physical storage of information that is usually grouped in the form of files. A specific file system determines the size of a file (folder) name, the maximum possible file and partition size, and a set of file attributes. Some file systems provide services, such as access control or file encryption.
File system tasks
The main functions of any file system are aimed at solving the following tasks:
file naming;
the program interface of work with files for applications;
mapping the logical model of the file system to the physical organization of the data warehouse;
organizing the stability of the file system 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 joint work 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 .
The file system is the main structure used by a computer to organize information on a hard drive. When installing a new hard drive it must be partitioned and formatted for a specific file system, after which it can store data and programs. Windows has three possible file system options: 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 earlier 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 prevent user access to certain files.
The FAT32 file system and the rarely used FAT system have been used in previous Windows versions, including Windows 95, Windows 98, and Windows Millennium Edition. The FAT32 file system does not provide the level of security that NTFS provides, so if a computer has a FAT32-formatted partition or volume, the files on that partition are visible to anyone with access to the computer. The FAT32 file system also has file size limits. In this version of Windows, it is not possible to create a FAT32 partition larger than 32GB. Also, a FAT32 partition cannot contain a file larger than 4GB.
The main reason for using the FAT32 system would be that the computer will be able to run both Windows 95, Windows 98, or Windows Millennium Edition, as well as this version of Windows (multi-OS configuration). To create such a configuration, you must install a previous version of the operating system on a partition formatted with FAT32 or FAT, making it the primary one (the primary partition can contain the operating system). Other sections accessed from previous versions Windows must also be formatted as FAT32. Earlier versions of Windows can only access NTFS network partitions or volumes. NTFS partitions on the local computer will not be available.
FAT - pluses:
Requires little to be effective random access memory.
Fast work with small and medium directories.
The disk makes fewer head movements on average (compared to NTFS).
Efficient work on slow disks.
FAT - cons:
Catastrophic loss of performance with increasing fragmentation, especially for large drives (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 pros:
File fragmentation has little to no effect on 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 particular obstacles to performance.
Quick access to an arbitrary fragment of a file (for example, editing large .wav files).
Very fast access to small files (several 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 slow down NTFS performance.
Working with directories of medium size is difficult because they are almost always fragmented.
A disk that has been running for a long time in a state of 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 is able to start): ext2fs, ext3fs, ext4fs, ReiserFS, XFS, JFS. It is they who are usually offered the choice when installing the vast majority of distributions. Of course, there are ways to install Linux on FAT / VFAT / FAT32 file systems, but this is only for those honeys and monsieurs who understand a lot about perversions, and I will not talk about them.
The main criteria for choosing a file system are usually reliability and speed. 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 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 it is the efficiency of working with small files that is the strength of this file system.
So, small files are files smaller than the logical block of the file system, which in Linux in most cases is equal to four kilobytes, although it can be set 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 ports, and similar ported 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 slower file operations. In particular, this is the reason for the catastrophic thoughtfulness of the FreeBSD file system (both the old, UFS, and the new, UFS2) when working with its own ports system.
In the ReiserFS file system, in such cases, separate blocks for data are not allocated - it manages to push the file data directly into the area of \u200b\u200bits own inode. 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 a legend about its unreliability. Indeed, when the file system crashes (that is, the service areas are destroyed), the data placed together with its inodes disappears along with them - and irretrievably. Whereas in those file systems where inodes and data blocks are always spatially separated, 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 are easily restored from the distribution kit.
Secondly, speaking about the possibility of recovering data from blocks that have lost their binding to their inodes, I did not accidentally use the word “theoretical”. Because in practice this occupation is extremely time-consuming, not giving a guaranteed result. Everyone who has had to do this will agree that one can indulge in it only out of complete hopelessness. And this applies to all Linux file systems. 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 even surpasses ext2. The results of comparing the speed of some common file file operations can be found here.
But with the compatibility of ReiserFS, the situation is somewhat worse. Access to it from the Windows OS, as far as I know, is not possible. 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 yesteryear does not have ReiserFS support is not zero.
And here it's time to remember about ext3fs. Its advantage is not at all in greater reliability - this is the same legend as the instability of ReiserFS. I've heard as much about ext3fs crashes as I've heard about ReiserFS crashes. I myself could not destroy either one or the other. Unless it worked with ext2 - but even that was 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 assistant - a situation that is almost not so unbelievable, I had to get into it. Again, most BSD systems understand ext3fs easily (albeit without journaling). For Windows, there are also, as far as I know, all kinds of drivers and plug-ins for common file managers(type Total Commander) that provide access to ext2fs/ext3fs partitions.
In terms of performance, ext3fs leaves a mixed impression. First, its performance is very dependent on the logging mode, of which there are three: with full data logging, partial data logging, and metadata-only logging. In each of the modes, it shows different performance on different types of file operations. However, in any case, the performance is not a record.
However, if the requirement for speed is put in the first place, then ext2fs is out of competition - however, in this case, you will have to put up with the lack of logging at all. And, consequently, with lengthy file system checks in case of any incorrect shutdown - and with the volume of modern disks, this can drag on for a long time ...
Concerning XFS it is possible to tell the following. In terms of compatibility, everything that is written for ReiserFS applies to it - moreover, until some time it was not supported by the standard Linux kernel. From the point of view of performance, it XFS also does not shine, speaking in total about the same level as ext3fs. And on the operation of deleting files, it generally demonstrates depressing slowness.
In my experience, using XFS pays off when working with not just large, but very large files - which are actually only DVD images and video files.
I return to the issue of reliability. A banal power off during normal user work, as a rule, painlessly transfers all journaled file systems (and none of them ensures the safety of user operations not written to disk - saving the drowning people and here 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, the occurrence of such situations is unlikely. 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, only their regular backup can be a guarantee of restoring destroyed data ...
I think the above information is enough for an informed choice. My personal choice over the past few years has been ReiserFS. Occasionally, on systems where it is justified to move everything that is possible outside the root partition, it is advisable to use ext3fs for the root file system and ReiserFS for everything else.
If a separate partition is provided for the /boot directory (and this is recommended when using the GRUB bootloader by its developers), then no other file system other than ext2fs is justified for it, any logging does not make sense here. Finally, if a separate partition is created 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 the dominant system. Since 2002, it has been replaced by the ext3 system, which is largely compatible with ext2, but also supports journaling functions, and, when working with kernel version 2.6 and higher, also ACL. The maximum file size is 2 TB, the maximum file system size is 8 TB. At the end of 2008, a version of ext4 was officially announced, which is backwards compatible with ext3, but many features are implemented more effectively than before. In addition, the maximum file system size is 1 EB (1,048,576 TB), and you can count on that for some time to be enough. About reiser - The system was named after its founder, Hans Reiser, and was the first system with logging functionality to access the Linux kernel for data. The SUSE version of zp was even considered the standard for some time. The main advantages of reiser over ext3 are faster performance and better allocation efficiency when working with small files (and most files in a file system tend to be small). Over time, however, the development of reisefers stopped. Version 4 was announced a long time ago, which is still not ready, and support for version 3 has ended. 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, in particular it is 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 has never really enjoyed much recognition in Linux and currently ekes out a miserable existence, inferior to other file systems.
brtfs
brtfs - if it is the will of the leading kernel developers, the brtfs filesystem in Linux has a bright future. This system was developed at Oracle from the ground up. It includes device-mapper and RAID support. Brtfs is most similar to Sun's ZFS. Its most interesting features include checking the file system on the go, as well as support for SSD (Solid State Drives are hard drives based on flash memory). Unfortunately, work on brtfs will not be completed in the foreseeable future. Since version 11 of Fedora, it is possible to install brtfs, but I recommend using it only for file system developers!
There is no "fastest" or "best" file system - the estimate depends on what you intend to use the system for. Novice Linux users working on a local computer are advised to work with ext3, and server administrators with ext4. Of course, ext4 is faster than ext3, but ext4 has significantly worse data reliability - you can easily lose information if the system suddenly shuts down.
If you installed a second UNIX-like operating system on your computer, then the following file systems will come in handy when exchanging data (from one OS to another).
sysv - used by SCO, Xenix and Coherent OS.
ufs - Used by FreeBSD, NetBSD, NextStep and SunOS. Linux can only read information from such file systems, but cannot make changes to the data. To access BSD segments, you will additionally need the BSD disklabel extension. A similar extension exists for SunOS partition tables.
ZFS is relative new system, developed by Sun for Solaris. Since the ZFS code does not comply with the GPL license, 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. The vfat system drivers allow you to work with old 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 usually use their own file systems.
iso9660 - The file system for CD-ROMs is described in the ISO-9660 standard, which allows only short filenames. Long names are supported in different operating systems in different ways, with the help of a variety of extensions that are incompatible with each other. A Linux system is capable of running both the Rockridge extension common to UNIX and the Joliet extension developed by Microsoft.
udf - this format (universal disk format) appeared and developed as the heir to ISO 9660.
Network file systems
Filesystems do not have to be on the local drive - they
can connect to a computer and through the network. The Linux kernel supports various network file systems, of which the following are the most commonly used.
smbfs/cifs - Helps to map 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 used by Novell Netware.
Virtual file systems
There are several file systems in Linux that are designed not to store data on a hard disk (or other media), but only to exchange information between the kernel and user programs.
devpts - This filesystem provides access to pseudo-terminals (PTY for short) via /dev/pts/* in accordance with the UNIX-98 specification. (Pseudo terminals emulate a serial interface. On UNIX/Linux systems, such interfaces are used by terminal emulators such as xterm. Devices such as /dev/ttypn are typically 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 the management of the kernel and processes. In addition to this, the sysfs filesystem builds relationships between the kernel and the hardware. Both filesystems are mounted at positions /proc and /sys.
tmpfs - This system is based on shared memory in accordance with System V. It is usually connected at position /dev/shm and provides an efficient exchange of information between two programs. On some distributions (eg Ubuntu), the /var/run and /var/lock directories are also created using the tmpfs file system. Files in these directories are used by some network daemons to store process identification numbers and file access information. Thanks to tmpfs, this data is now reflected in RAM. The method guarantees high speed, as well as the fact that after shutting down the computer, no files will remain in the /var/run or /var/lock directories.
usbfs - the usbfs file system, starting from kernel version 2.6 and higher, gives 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 with that name. However, the word auto can be used in /etc/fstab or with the mount command to specify a filesystem. 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 execute the mount command for the selected file systems. If a file system has not been used for some time, then the umount command is automatically executed for it. This method is useful primarily in cases where only a few of the many NFS directories are actively used at the same time.
To perform these operations, the /etc/init.d/ autofs script automatically executes the automount program at system startup. It is configured using the /etc/auto.master file. Appropriate programs are automatically installed in, for example, Red Hat and Fedora. In any case, autofs is only enabled after configuring /etc/auto.master or /etc/auto.misc.
cramfs and squashfs
cramfs and squashfs - Cram and Squash filesystems are read-only. They are used to "pack" as many zipped files into flash memory or ROM (Read Only Memory) as possible.
fuse - FUSE stands for "Filesystem in Userspace" and allows the development and use of filesystem drivers outside the kernel. Therefore, FUSE is always used with an external file system driver. FUSE works with the ntfs-3g NTFS driver in particular.
gfs and ocfs - Oracle's Global File System and 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 specially optimized for working with solid state drives and flash media. Using special algorithms, they try to evenly use all memory cells (wear leveling technology) in order to avoid premature system failure.
loop
loop - used to work with pseudo devices. A loopback device is an adapter capable of accessing a regular file as if it were a block device. Thanks to him, 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 various ways to use pseudo-devices. In particular, they can be used when creating disks in RAM for initial initialization (Initial RAM disk) for GRUB or LILO, when implementing encrypted file systems or testing ISO images for CD.
Storage media file systems
File systems
ISO 9660
Joliet extension of the ISO 9660 file system.
Rock Ridge (RRIP, IEEE P1282) is 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 A specification for an operating system-independent file system format for storing files on optical media. UDF is an implementation of the ISO/IEC 13346 standard
Mount Rainier
