- Ubuntu Documentation
- Introduction to File systems
- Journaling
- Table
- File systems
- Contents
- Types of file systems
- Journaling
- FUSE-based file systems
- Stackable file systems
- Read-only file systems
- Clustered file systems
- Shared-disk file system
- Identify existing file systems
- Create a file system
- Mount a file system
- List mounted file systems
Ubuntu Documentation
Introduction to File systems
File systems are one of the things any newcomer to linux must become acquainted with. In the world of Microsoft you never really have to worry about it, the default being NTFS. Linux however, being built on a world of open source and differing opinions, is not limited in this way and so the user should have an understanding of what a file system is, and how it affects the computer.
At the core of a computer, it’s all 1s and 0s, but the organization of that data is not quite as simple. A bit is a 1 or a 0, a byte is composed of 8 bits, a kibibyte is 1024 (i.e. 2^10) bytes, a mebibyte is 1024 kibibytes and so on and so forth. All these bits and bytes are permanently stored on a Hard Drive. A hard drive stores all your data, any time you save a file, you’re writing thousands of 1s and 0s to a metallic disc, changing the magnetic properties that can later be read as 1 or 0. There is so much data on a hard drive that there has to be some way to organize it, like a library of books and the old card drawers that indexed all of them, without that index, we’d be lost. Libraries, for the most part, use the Dewey Decimal System to organize their books, but there exist other systems to do so, none of which have attained the same fame as Mr. Dewey’s invention. File systems are the same way. The ones most users are aware of are the ones Windows uses, the vFat or the NTFS systems, these are the Windows default file systems.
There are several different attributes which are necessary in defining file systems, these include their max file size, max partition size, whether they journal or not.
Journaling
A journaling file system is more reliable when it comes to data storage. Journaling file systems do not necessarily prevent corruption, but they do prevent inconsistency and are much faster at file system checks than non-journaled file systems. If a power failure happens while you are saving a file, the save will not complete and you end up with corrupted data and an inconsistent file system. Instead of actually writing directly to the part of the disk where the file is stored, a journaling file system first writes it to another part of the hard drive and notes the necessary changes to a log, then in the background it goes through each entry to the journal and begins to complete the task, and when the task is complete, it checks it off on the list. Thus the file system is always in a consistent state (the file got saved, the journal reports it as not completely saved, or the journal is inconsistent (but can be rebuilt from the file system)). Some journaling file systems can prevent corruption as well by writing data twice.
Table
Now below is a very brief comparison of the most common file systems in use with the Linux world.
Источник
File systems
In computing, a file system or filesystem controls how data is stored and retrieved. Without a file system, information placed in a storage medium would be one large body of data with no way to tell where one piece of information stops and the next begins. By separating the data into pieces and giving each piece a name, the information is easily isolated and identified. Taking its name from the way paper-based information systems are named, each group of data is called a «file». The structure and logic rules used to manage the groups of information and their names is called a «file system».
Individual drive partitions can be setup using one of the many different available filesystems. Each has its own advantages, disadvantages, and unique idiosyncrasies. A brief overview of supported filesystems follows; the links are to Wikipedia pages that provide much more information.
Contents
Types of file systems
The factual accuracy of this article or section is disputed.
See filesystems(5) for a general overview and Wikipedia:Comparison of file systems for a detailed feature comparison. File systems supported by the kernel are listed in /proc/filesystems .
File system | Creation command | Userspace utilities | Archiso [1] | Kernel documentation [2] | Notes |
---|---|---|---|---|---|
Btrfs | mkfs.btrfs(8) | btrfs-progs | Yes | btrfs.html | Stability status |
VFAT | mkfs.fat(8) | dosfstools | Yes | vfat.html | Windows 9x file system |
exFAT | mkfs.exfat(8) | exfatprogs | Yes | Native file system in Linux 5.4. [3] | |
mkexfatfs(8) | exfat-utils | No | N/A (FUSE-based) | ||
F2FS | mkfs.f2fs(8) | f2fs-tools | Yes | f2fs.html | Flash-based devices |
ext3 | mkfs.ext3(8) | e2fsprogs | Yes | ext3.html | |
ext4 | mkfs.ext4(8) | e2fsprogs | Yes | ext4.html | |
HFS | mkfs.hfsplus(8) | hfsprogs AUR | No | hfs.html | Classic Mac OS file system |
HFS+ | mkfs.hfsplus(8) | hfsprogs AUR | No | hfsplus.html | macOS (8–10.12) file system |
JFS | mkfs.jfs(8) | jfsutils | Yes | jfs.html | |
NILFS2 | mkfs.nilfs2(8) | nilfs-utils | Yes | nilfs2.html | Raw flash devices, e.g. SD card |
NTFS | No | ntfs.html | Windows NT file system. Kernel’s in-built driver has very limited write support. officially supported kernels are built without CONFIG_NTFS_FS so this driver is not available. | ||
mkfs.ntfs(8) | ntfs-3g | Yes | N/A (FUSE-based) | FUSE driver with extended capabilities. | |
ReiserFS | mkfs.reiserfs(8) | reiserfsprogs | Yes | ||
UDF | mkfs.udf(8) | udftools | Yes | udf.html | |
XFS | mkfs.xfs(8) | xfsprogs | Yes |
File system | Creation command | Kernel patchset | Userspace utilities | Notes |
---|---|---|---|---|
APFS | mkapfs(8) | linux-apfs-rw-dkms-git AUR | apfsprogs-git AUR | macOS (10.13 and newer) file system. Read only, experimental. |
Bcachefs | bcachefs(8) | linux-bcachefs-git AUR | bcachefs-tools-git AUR | |
NTFS3 | ntfs3-dkms AUR | Paragon NTFS3 driver FAQ | ||
Reiser4 | mkfs.reiser4(8) | reiser4progs AUR | ||
ZFS | zfs-linux AUR , zfs-dkms AUR | zfs-utils AUR | OpenZFS port |
Journaling
All the above filesystems with the exception of exFAT, ext2, FAT16/32, Reiser4 (optional), Btrfs and ZFS, use journaling. Journaling provides fault-resilience by logging changes before they are committed to the filesystem. In the event of a system crash or power failure, such file systems are faster to bring back online and less likely to become corrupted. The logging takes place in a dedicated area of the filesystem.
Not all journaling techniques are the same. Ext3 and ext4 offer data-mode journaling, which logs both data and meta-data, as well as possibility to journal only meta-data changes. Data-mode journaling comes with a speed penalty and is not enabled by default. In the same vein, Reiser4 offers so-called «transaction models» which not only change the features it provides, but in its journaling mode. It uses a different journaling techniques: a special model called wandering logs which eliminates the need to write to the disk twice, write-anywhere—a pure copy-on-write approach (mostly equivalent to btrfs’ default but with a fundamentally different «tree» design) and a combined approach called hybrid which heuristically alternates between the two former.
The other filesystems provide ordered-mode journaling, which only logs meta-data. While all journaling will return a filesystem to a valid state after a crash, data-mode journaling offers the greatest protection against corruption and data loss. There is a compromise in system performance, however, because data-mode journaling does two write operations: first to the journal and then to the disk (which Reiser4 avoids with its «wandering logs» feature). The trade-off between system speed and data safety should be considered when choosing the filesystem type. Reiser4 is the only filesystem that by design operates on full atomicity and also provides checksums for both meta-data and inline data (operations entirely occur, or they entirely do not and does not corrupt or destroy data due to operations half-occurring) and by design is therefore much less prone to data loss than other file systems like Btrfs.
Filesystems based on copy-on-write (also known as write-anywhere), such as Reiser4, Btrfs and ZFS, have no need to use traditional journal to protect metadata, because they are never updated in-place. Although Btrfs still has a journal-like log tree, it is only used to speed-up fdatasync/fsync.
FUSE-based file systems
Stackable file systems
- aufs — Advanced Multi-layered Unification Filesystem, a FUSE based union filesystem, a complete rewrite of Unionfs, was rejected from Linux mainline and instead OverlayFS was merged into the Linux Kernel.
http://aufs.sourceforge.net || linux-aufsAUR
- eCryptfs — The Enterprise Cryptographic Filesystem is a package of disk encryption software for Linux. It is implemented as a POSIX-compliant filesystem-level encryption layer, aiming to offer functionality similar to that of GnuPG at the operating system level.
https://ecryptfs.org || ecryptfs-utils
- mergerfs — a FUSE based union filesystem.
https://github.com/trapexit/mergerfs || mergerfsAUR
- mhddfs — Multi-HDD FUSE filesystem, a FUSE based union filesystem.
http://mhddfs.uvw.ru || mhddfsAUR
- overlayfs — OverlayFS is a filesystem service for Linux which implements a union mount for other file systems.
https://www.kernel.org/doc/html/latest/filesystems/overlayfs.html || linux
- Unionfs — Unionfs is a filesystem service for Linux, FreeBSD and NetBSD which implements a union mount for other file systems.
https://unionfs.filesystems.org/ || not packaged? search in AUR
- unionfs-fuse — A user space Unionfs implementation.
https://github.com/rpodgorny/unionfs-fuse || unionfs-fuse
Read-only file systems
- EROFS — Enhanced Read-Only File System is a lightweight read-only file system, it aims to improve performance and compress storage capacity.
https://www.kernel.org/doc/html/latest/filesystems/erofs.html || erofs-utils
- SquashFS — SquashFS is a compressed read only filesystem. SquashFS compresses files, inodes and directories, and supports block sizes up to 1 MB for greater compression.
https://github.com/plougher/squashfs-tools || squashfs-tools
Clustered file systems
- Ceph — Unified, distributed storage system designed for excellent performance, reliability and scalability.
https://ceph.com/ || ceph
- Glusterfs — Cluster file system capable of scaling to several peta-bytes.
https://www.gluster.org/ || glusterfs
- IPFS — A peer-to-peer hypermedia protocol to make the web faster, safer, and more open. IPFS aims replace HTTP and build a better web for all of us. Uses blocks to store parts of a file, each network node stores only content it is interested, provides deduplication, distribution, scalable system limited only by users. (currently in alpha)
https://ipfs.io/ || go-ipfs
- MooseFS — MooseFS is a fault tolerant, highly available and high performance scale-out network distributed file system.
https://moosefs.com || moosefs
- OpenAFS — Open source implementation of the AFS distributed file system
https://www.openafs.org || openafsAUR
- OrangeFS — OrangeFS is a scale-out network file system designed for transparently accessing multi-server-based disk storage, in parallel. Has optimized MPI-IO support for parallel and distributed applications. Simplifies the use of parallel storage not only for Linux clients, but also for Windows, Hadoop, and WebDAV. POSIX-compatible. Part of Linux kernel since version 4.6.
https://www.orangefs.org/ || not packaged? search in AUR
- Sheepdog — Distributed object storage system for volume and container services and manages the disks and nodes intelligently.
https://sheepdog.github.io/sheepdog/ || sheepdogAUR
- Tahoe-LAFS — Tahoe Least-Authority Filesystem is a free and open, secure, decentralized, fault-tolerant, peer-to-peer distributed data store and distributed file system.
https://tahoe-lafs.org/ || tahoe-lafsAUR
Shared-disk file system
- GFS2 — GFS2 allows all members of a cluster to have direct concurrent access to the same shared block storage
https://pagure.io/gfs2-utils || gfs2-utilsAUR
- OCFS2 — The Oracle Cluster File System (version 2) is a shared disk file system developed by Oracle Corporation and released under the GNU General Public License
https://oss.oracle.com/projects/ocfs2/ || ocfs2-toolsAUR
- VMware VMFS — VMware’s VMFS (Virtual Machine File System) is used by the company’s flagship server virtualization suite, vSphere.
https://www.vmware.com/products/vi/esx/vmfs.html || vmfs-toolsAUR
Identify existing file systems
To identify existing file systems, you can use lsblk:
An existing file system, if present, will be shown in the FSTYPE column. If mounted, it will appear in the MOUNTPOINT column.
Create a file system
File systems are usually created on a partition, inside logical containers such as LVM, RAID and dm-crypt, or on a regular file (see Wikipedia:Loop device). This section describes the partition case.
Before continuing, identify the device where the file system will be created and whether or not it is mounted. For example:
Mounted file systems must be unmounted before proceeding. In the above example an existing filesystem is on /dev/sda2 and is mounted at /mnt . It would be unmounted with:
To find just mounted file systems, see #List mounted file systems.
To create a new file system, use mkfs(8) . See #Types of file systems for the exact type, as well as userspace utilities you may wish to install for a particular file system.
For example, to create a new file system of type ext4 (common for Linux data partitions) on /dev/sda1 , run:
The new file system can now be mounted to a directory of choice.
Mount a file system
To manually mount filesystem located on a device (e.g., a partition) to a directory, use mount(8) . This example mounts /dev/sda1 to /mnt .
This attaches the filesystem on /dev/sda1 at the directory /mnt , making the contents of the filesystem visible. Any data that existed at /mnt before this action is made invisible until the device is unmounted.
fstab contains information on how devices should be automatically mounted if present. See the fstab article for more information on how to modify this behavior.
If a device is specified in /etc/fstab and only the device or mount point is given on the command line, that information will be used in mounting. For example, if /etc/fstab contains a line indicating that /dev/sda1 should be mounted to /mnt , then the following will automatically mount the device to that location:
mount contains several options, many of which depend on the file system specified. The options can be changed, either by:
- using flags on the command line with mount
- editing fstab
- creating udev rules
- compiling the kernel yourself
- or using filesystem-specific mount scripts (located at /usr/bin/mount.* ).
See these related articles and the article of the filesystem of interest for more information.
List mounted file systems
To list all mounted file systems, use findmnt(8) :
findmnt takes a variety of arguments which can filter the output and show additional information. For example, it can take a device or mount point as an argument to show only information on what is specified:
findmnt gathers information from /etc/fstab , /etc/mtab , and /proc/self/mounts .
Источник