Katana VentraIP

File system

In computing, a file system or filesystem (often abbreviated to FS or fs) governs file organization and access. A local file system is a capability of an operating system that services the applications running on the same computer.[1][2] A distributed file system is a protocol that provides file access between networked computers.

This article is about how a computer organizes and accesses computer files. For library and office filing systems, see Library classification.

A file system provides a data storage service that allows applications to share mass storage. Without a file system, applications could access the storage in incompatible ways that lead to resource contention, data corruption and data loss.


There are many file system designs and implementations – with various structure and features and various resulting characteristics such as speed, flexibility, security, size and more.


Files systems have been developed for many types of storage devices, including hard disk drives (HDDs), solid-state drives (SSDs), magnetic tapes and optical discs.[3]


A portion of the computer main memory can be set up as a RAM disk that serves as a storage device for a file system. File systems such as tmpfs can store files in virtual memory.


A virtual file system provides access to files that are either computed on request, called virtual files (see procfs and sysfs), or are mapping into another, backing storage.

Etymology[edit]

From c. 1900 and before the advent of computers the terms file system, filing system and system for filing were used to describe methods of organizing, storing and retrieving paper documents.[4] By 1961, the term file system was being applied to computerized filing alongside the original meaning.[5] By 1964, it was in general use.[6]

Architecture[edit]

A local file system's architecture can be described as layers of abstraction even though a particular file system design may not actually separate the concepts.[7]


The logical file system layer provides relatively high-level access via an application programming interface (API) for file operations including open, close, read and write – delegating operations to lower layers. This layer manages open file table entries and per-process file descriptors.[8] It provides file access, directory operations, security and protection.[7]


The virtual file system, an optional layer, supports multiple concurrent instances of physical file systems, each of which called a file system implementation.[8]


The physical file system layer provides relatively low-level access to a storage device (e.g. disk). It reads and writes data blocks, provides buffering and other memory management and controls placement of blocks in specific locations on the storage medium. This layer uses device drivers or channel I/O to drive the storage device.[7]

name

which may be stored as the number of blocks allocated or as a byte count

size

created, last accessed, last backed-up

when

owner and group

user

access permissions

such as whether the file is read-only, executable, etc.

file attributes

(e.g. block, character, socket, subdirectory, etc.)

device type

Types[edit]

Disk file systems[edit]

A disk file system takes advantages of the ability of disk storage media to randomly address data in a short amount of time. Additional considerations include the speed of accessing data following that initially requested and the anticipation that the following data may also be requested. This permits multiple users (or processes) access to various data on the disk without regard to the sequential location of the data. Examples include FAT (FAT12, FAT16, FAT32), exFAT, NTFS, ReFS, HFS and HFS+, HPFS, APFS, UFS, ext2, ext3, ext4, XFS, btrfs, Files-11, Veritas File System, VMFS, ZFS, ReiserFS, NSS and ScoutFS. Some disk file systems are journaling file systems or versioning file systems.

In many situations, file systems other than the root need to be available as soon as the operating system has . All Unix-like systems therefore provide a facility for mounting file systems at boot time. System administrators define these file systems in the configuration file fstab (vfstab in Solaris), which also indicates options and mount points.

booted

In some situations, there is no need to mount certain file systems at , although their use may be desired thereafter. There are some utilities for Unix-like systems that allow the mounting of predefined file systems upon demand.

boot time

Removable media allow programs and data to be transferred between machines without a physical connection. Common examples include , CD-ROMs, and DVDs. Utilities have therefore been developed to detect the presence and availability of a medium and then mount that medium without any user intervention.

USB flash drives

Progressive Unix-like systems have also introduced a concept called supermounting; see, for example, . For example, a floppy disk that has been supermounted can be physically removed from the system. Under normal circumstances, the disk should have been synchronized and then unmounted before its removal. Provided synchronization has occurred, a different disk can be inserted into the drive. The system automatically notices that the disk has changed and updates the mount point contents to reflect the new medium.

the Linux supermount-ng project

An will automatically mount a file system when a reference is made to the directory atop which it should be mounted. This is usually used for file systems on network servers, rather than relying on events such as the insertion of media, as would be appropriate for removable media.

automounter

Limitations[edit]

Design limitations[edit]

File systems limit storable data capacity – generally driven by the typical size of storage devices at the time the file system is designed and anticipated into the foreseeable future.


Since storage sizes have increased at near exponential rate (see Moore's law), newer storage devices often exceed existing file system limits within only a few years after introduction. This requires new file systems with ever increasing capacity.


With higher capacity, the need for capabilities and therefore complexity increases as well. File system complexity typically varies proportionally with available storage capacity. Capacity issues aside, the file systems of early 1980s home computers with 50 KB to 512 KB of storage would not be a reasonable choice for modern storage systems with hundreds of gigabytes of capacity. Likewise, modern file systems would not be a reasonable choice for these early systems, since the complexity of modern file system structures would quickly consume the limited capacity of early storage systems.

Converting the type of a file system[edit]

It may be advantageous or necessary to have files in a different file system than they currently exist. Reasons include the need for an increase in the space requirements beyond the limits of the current file system. The depth of path may need to be increased beyond the restrictions of the file system. There may be performance or reliability considerations. Providing access to another operating system which does not support the existing file system is another reason.

. Archived from the original on 2015-11-03.{{cite web}}: CS1 maint: unfit URL (link)

"Filesystem Specifications - Links & Whitepapers"

Interesting File System Projects