Editing File system (section)

== Types ==

=== Disk file systems ===

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 [[File Allocation Table|FAT]] ([[FAT12]], [[FAT16]], [[FAT32]]), [[exFAT]], [[NTFS]], [[ReFS]], [[Hierarchical File System (Apple)|HFS]] and [[HFS Plus|HFS+]], [[High Performance File System|HPFS]], [[Apple File System|APFS]], [[Unix File System|UFS]], [[ext2]], [[ext3]], [[ext4]], [[XFS]], [[btrfs]], [[Files-11]], [[Veritas File System]], [[VMFS]], [[ZFS]], [[ReiserFS]], [[Novell Storage Services|NSS]] and ScoutFS. Some disk file systems are [[journaling file system]]s or [[versioning file system]]s.

==== Optical discs ====

[[ISO 9660]] and [[Universal Disk Format]] (UDF) are two common formats that target [[Compact Disc]]s, [[DVD]]s and [[Blu-ray]] [[optical disc|discs]]. [[Mount Rainier (packet writing)|Mount Rainier]] is an extension to UDF supported since 2.6 series of the Linux kernel and since Windows Vista that facilitates rewriting to DVDs.

=== Flash file systems ===
{{Main|Flash file system}}

A ''flash file system'' considers the special abilities, performance and restrictions of [[flash memory]] devices. Frequently a disk file system can use a flash memory device as the underlying storage media, but it is much better to use a file system specifically designed for a flash device.<ref>{{cite book|chapter=18. Storage Alternatives for Mobile Computers|title=Mobile Computing|last1=Douglis|first1=Fred|last2=Cáceres|first2=Ramón|last3=Kaashoek|first3=M. Frans|author3-link=Frans Kaashoek|last4=Krishnan|first4=P.|last5=Li|first5=Kai|author6-link=Kai Li|last6=Marsh|first6=Brian|last7=Tauber|first7=Joshua|publisher=[[USENIX]]|date=1994|volume=353|pages=473–505|isbn=978-0-585-29603-6|doi=10.1007/978-0-585-29603-6_18|s2cid=2441760 }}</ref>

=== Tape file systems ===

A ''tape file system'' is a file system and tape format designed to store files on tape. [[Magnetic tape]]s are sequential storage media with significantly longer random data access times than disks, posing challenges to the creation and efficient management of a general-purpose file system.

In a disk file system there is typically a master file directory, and a map of used and free data regions. Any file additions, changes, or removals require updating the directory and the used/free maps. Random access to data regions is measured in milliseconds so this system works well for disks.

Tape requires linear motion to wind and unwind potentially very long reels of media. This tape motion may take several seconds to several minutes to move the read/write head from one end of the tape to the other.

Consequently, a master file directory and usage map can be extremely slow and inefficient with tape. Writing typically involves reading the block usage map to find free blocks for writing, updating the usage map and directory to add the data, and then advancing the tape to write the data in the correct spot. Each additional file write requires updating the map and directory and writing the data, which may take several seconds to occur for each file.

Tape file systems instead typically allow for the file directory to be spread across the tape intermixed with the data, referred to as ''streaming'', so that time-consuming and repeated tape motions are not required to write new data.

However, a side effect of this design is that reading the file directory of a tape usually requires scanning the entire tape to read all the scattered directory entries. Most data archiving software that works with tape storage will store a local copy of the tape catalog on a disk file system, so that adding files to a tape can be done quickly without having to rescan the tape media. The local tape catalog copy is usually discarded if not used for a specified period of time, at which point the tape must be re-scanned if it is to be used in the future.

IBM has developed a file system for tape called the [[Linear Tape File System]]. The IBM implementation of this file system has been released as the open-source [[Linear Tape File System#IBM Linear Tape File System - Single Drive Edition|IBM Linear Tape File System — Single Drive Edition (LTFS-SDE)]] product. The Linear Tape File System uses a separate partition on the tape to record the index meta-data, thereby avoiding the problems associated with scattering directory entries across the entire tape.

==== Tape formatting ====

Writing data to a tape, erasing, or formatting a tape is often a significantly time-consuming process and can take several hours on large tapes.{{Efn|An LTO-6 2.5 TB tape requires more than 4 hours to write at 160 MB/Sec}} With many data tape technologies it is not necessary to format the tape before over-writing new data to the tape. This is due to the inherently destructive nature of overwriting data on sequential media.

Because of the time it can take to format a tape, typically tapes are pre-formatted so that the tape user does not need to spend time preparing each new tape for use. All that is usually necessary is to write an identifying media label to the tape before use, and even this can be automatically written by software when a new tape is used for the first time.

===Database file systems===
Another concept for file management is the idea of a database-based file system. Instead of, or in addition to, hierarchical structured management, files are identified by their characteristics, like type of file, topic, author, or similar [[metadata (computing)|rich metadata]].<ref>{{cite web|url=https://www.theregister.co.uk/2002/03/29/windows_on_a_database_sliced/ |title=Windows on a database – sliced and diced by BeOS vets |publisher=theregister.co.uk |date=2002-03-29 |access-date=2014-02-07}}</ref>

IBM DB2 for i <ref>{{cite web|url=http://www-03.ibm.com/systems/i/software/db2/index.html |title=IBM DB2 for i: Overview |publisher=03.ibm.com |access-date=2014-02-07 |archive-url=https://web.archive.org/web/20130802153156/http://www-03.ibm.com/systems/i/software/db2/index.html |archive-date=2013-08-02 |url-status=dead}}</ref> (formerly known as DB2/400 and DB2 for i5/OS) is a database file system as part of the object based [[IBM i]]<ref>{{cite web|url=http://www.ibm.com/developerworks/ibmi/newto/ |title=IBM developerWorks : New to IBM i |publisher=Ibm.com |date=2011-03-08 |access-date=2014-02-07}}</ref> operating system (formerly known as OS/400 and i5/OS), incorporating a [[Single-level store|single level store]] and running on IBM Power Systems (formerly known as AS/400 and iSeries), designed by Frank G. Soltis IBM's former chief scientist for IBM i. Around 1978 to 1988 Frank G. Soltis and his team at IBM Rochester had successfully designed and applied technologies like the database file system where others like Microsoft later failed to accomplish.<ref>{{cite web |url=https://www.theregister.co.uk/2002/01/28/xp_successor_longhorn_goes_sql/ |title=XP successor Longhorn goes SQL, P2P – Microsoft leaks |publisher=theregister.co.uk |date=2002-01-28 |access-date=2014-02-07}}</ref> These technologies are informally known as 'Fortress Rochester'{{Citation needed|date = June 2014|reason = Any news report or blog article mentioning this name and relating it to IBM i?}} and were in few basic aspects extended from early Mainframe technologies but in many ways more advanced from a technological perspective{{Citation needed|date = June 2014|reason = Is there any articles supporting this technological superiority?}}.

Some other projects that are not "pure" database file systems but that use some aspects of a database file system:
* Many [[Web content management system]]s use a [[Database management system|relational DBMS]] to store and retrieve files. For example, [[XHTML]] files are stored as [[XML]] or text fields, while image files are stored as blob fields; [[SQL]] SELECT (with optional [[XPath]]) statements retrieve the files, and allow the use of a sophisticated logic and more rich information associations than "usual file systems." Many CMSs also have the option of storing only [[metadata]] within the database, with the standard filesystem used to store the content of files.
* Very large file systems, embodied by applications like [[Apache Hadoop]] and [[Google File System]], use some ''database file system'' concepts.

===Transactional file systems===
Some programs need to either make multiple file system changes, or, if one or more of the changes fail for any reason, make none of the changes. For example, a program which is installing or updating software may write executables, libraries, and/or configuration files. If some of the writing fails and the software is left partially installed or updated, the software may be broken or unusable. An incomplete update of a key system utility, such as the command [[shell (computing)|shell]], may leave the entire system in an unusable state.

[[Transaction processing]] introduces the [[Atomicity (programming)|atomicity]] guarantee, ensuring that operations inside of a transaction are either all committed or the transaction can be aborted and the system discards all of its partial results. This means that if there is a crash or power failure, after recovery, the stored state will be consistent. Either the software will be completely installed or the failed installation will be completely rolled back, but an unusable partial install will not be left on the system. Transactions also provide the [[isolation (database systems)|isolation]] guarantee{{Clarify|reason=Complicated terms|date=June 2017}}, meaning that operations within a transaction are hidden from other threads on the system until the transaction commits, and that interfering operations on the system will be properly [[Serialization|serialized]] with the transaction.

Windows, beginning with Vista, added transaction support to [[NTFS]], in a feature called [[Transactional NTFS]], but its use is now discouraged.<ref>{{cite web|url=http://msdn.microsoft.com/en-us/library/windows/desktop/hh802690(v=vs.85).aspx |title=Alternatives to using Transactional NTFS (Windows) |publisher=Msdn.microsoft.com |date=2013-12-05 |access-date=2014-02-07}}</ref> There are a number of research prototypes of transactional file systems for UNIX systems, including the Valor file system,<ref>{{cite conference|last1=Spillane|first1=Richard|last2=Gaikwad|first2=Sachin|last3=Chinni|first3=Manjunath|last4=Zadok|first4=Erez|last5=Wright|first5=Charles P.|date=2009|url=http://www.fsl.cs.sunysb.edu/docs/valor/valor_fast2009.pdf|title=Enabling transactional file access via lightweight kernel extensions|conference=Seventh USENIX Conference on File and Storage Technologies (FAST 2009)}}</ref> Amino,<ref>{{cite journal|last1=Wright|first1=Charles P.|last2=Spillane|first2=Richard|last3=Sivathanu|first3=Gopalan|last4=Zadok|first4=Erez|date=2007|url=http://www.fsl.cs.sunysb.edu/docs/amino-tos06/amino.pdf|title=Extending ACID Semantics to the File System|journal=ACM Transactions on Storage|volume=3 |issue=2 |page=4 |doi=10.1145/1242520.1242521 |s2cid=8939577 }}</ref> LFS,<ref>{{cite conference|last=Seltzer|first=Margo I.|author-link=Margo Seltzer|date=1993|url=http://www.eecs.harvard.edu/~margo/papers/icde93/paper.pdf|title=Transaction Support in a Log-Structured File System|book-title=Proceedings of the Ninth International Conference on Data Engineering}}</ref> and a transactional [[ext3]] file system on the TxOS kernel,<ref>{{cite conference|last1=Porter|first1=Donald E.|last2=Hofmann|first2=Owen S.|last3=Rossbach|first3=Christopher J.|last4=Benn|first4=Alexander|last5=Witchel|first5=Emmett|url=http://www.sigops.org/sosp/sosp09/papers/porter-sosp09.pdf|title=Operating System Transactions|book-title=Proceedings of the 22nd ACM Symposium on Operating Systems Principles (SOSP '09)|location=Big Sky, MT|date=October 2009}}</ref> as well as transactional file systems targeting embedded systems, such as TFFS.<ref>{{cite conference|last1=Gal|first1=Eran|last2=Toledo|first2=Sivan|url=http://www.usenix.org/event/usenix05/tech/general/full_papers/gal/gal.pdf|title=A Transactional Flash File System for Microcontrollers|conference=USENIX 2005}}</ref>

Ensuring consistency across multiple file system operations is difficult, if not impossible, without file system transactions. [[File locking]] can be used as a [[concurrency control]] mechanism for individual files, but it typically does not protect the directory structure or file metadata. For instance, file locking cannot prevent [[TOCTTOU]] race conditions on symbolic links.
File locking also cannot automatically roll back a failed operation, such as a software upgrade; this requires atomicity.

[[Journaling file system]]s is one technique used to introduce transaction-level consistency to file system structures. Journal transactions are not exposed to programs as part of the OS API; they are only used internally to ensure consistency at the granularity of a single system call.

Data backup systems typically do not provide support for direct backup of data stored in a transactional manner, which makes the recovery of reliable and consistent data sets difficult. Most backup software simply notes what files have changed since a certain time, regardless of the transactional state shared across multiple files in the overall dataset. As a workaround, some database systems simply produce an archived state file containing all data up to that point, and the backup software only backs that up and does not interact directly with the active transactional databases at all. Recovery requires separate recreation of the database from the state file after the file has been restored by the backup software.

===Network file systems===
{{Main|Distributed file system}}

A ''network file system'' is a file system that acts as a client for a remote file access protocol, providing access to files on a server. Programs using local interfaces can transparently create, manage and access hierarchical directories and files in remote network-connected computers. Examples of network file systems include clients for the [[Network File System (protocol)|NFS]],<ref>{{citation|title=Sun's Network File System|url=http://pages.cs.wisc.edu/~remzi/OSTEP/dist-nfs.pdf|publisher= Arpaci-Dusseau Books|year = 2014|first1 = Remzi H.|last1 =Arpaci-Dusseau|first2=Andrea C.|last2 = Arpaci-Dusseau}}</ref> [[Andrew File System|AFS]], [[Server Message Block|SMB]] protocols, and file-system-like clients for [[File Transfer Protocol|FTP]] and [[WebDAV]].

===Shared disk file systems===
{{Main|Shared disk file system}}

A ''shared disk file system'' is one in which a number of machines (usually servers) all have access to the same external disk subsystem (usually a [[storage area network]]). The file system arbitrates access to that subsystem, preventing write collisions.<ref>{{cite book|url=https://books.google.com/books?id=TUtrRoDhNm4C&pg=PA124|title=Storage Networks Explained: Basics and Application of Fibre Channel SAN, NAS, iSCSI and InfiniBand|last1=Troppens|first1=Ulf|last2=Erkens|first2=Rainer|last3=Müller|first3=Wolfgang|publisher=[[John Wiley & Sons]]|date=2004|access-date=June 30, 2022|pages=124–125|isbn=0-470-86182-7}}</ref> Examples include [[GFS2]] from [[Red Hat]], [[IBM General Parallel File System|GPFS]], now known as Spectrum Scale, from IBM, [[SAN File System|SFS]] from DataPlow, [[CXFS]] from [[Silicon Graphics International|SGI]], [[StorNext]] from [[Quantum Corporation]] and ScoutFS from Versity.

=== Special file systems ===
{{anchor|special file system}}

Some file systems expose elements of the operating system as files so they can be acted on via the [[file system API]]. This is common in [[Unix-like]] operating systems, and to a lesser extent in other operating systems. Examples include:

{{anchor|device file system}}
* [[devfs]], [[udev]], [[TOPS-10]] expose I/O devices or pseudo-devices as special files
* [[configfs]] and [[sysfs]] expose special files that can be used to query and configure [[Linux]] kernel information
* [[procfs]] exposes process information as special files

===Minimal file system / audio-cassette storage===
In the 1970s disk and digital tape devices were too expensive for some early [[microcomputer]] users. An inexpensive basic data storage system was devised that used common [[audio cassette]] tape.

When the system needed to write data, the user was notified to press "RECORD" on the cassette recorder, then press "RETURN" on the keyboard to notify the system that the cassette recorder was recording. The system wrote a sound to provide time synchronization, then [[Kansas City standard|modulated sounds]] that encoded a prefix, the data, a [[checksum]] and a suffix. When the system needed to read data, the user was instructed to press "PLAY" on the cassette recorder. The system would ''listen'' to the sounds on the tape waiting until a burst of sound could be recognized as the synchronization. The system would then interpret subsequent sounds as data. When the data read was complete, the system would notify the user to press "STOP" on the cassette recorder. It was primitive, but it (mostly) worked. Data was stored sequentially, usually in an unnamed format, although some systems (such as the [[Commodore PET]] series of computers) did allow the files to be named. Multiple sets of data could be written and located by fast-forwarding the tape and observing at the tape counter to find the approximate start of the next data region on the tape. The user might have to listen to the sounds to find the right spot to begin playing the next data region. Some implementations even included audible sounds interspersed with the data.

===Flat file systems===
<!-- linked from redirect [[Flat file system]] -->
{{distinguish|Flat file database}}
In a flat file system, there are no [[subdirectory|subdirectories]]; directory entries for all files are stored in a single directory.

When [[floppy disk]] media was first available this type of file system was adequate due to the relatively small amount of data space available. [[CP/M]] machines featured a flat file system, where files could be assigned to one of 16 ''user areas'' and generic file operations narrowed to work on one instead of defaulting to work on all of them. These user areas were no more than special attributes associated with the files; that is, it was not necessary to define specific [[Disk quota|quota]] for each of these areas and files could be added to groups for as long as there was still free storage space on the disk. The early [[Apple Macintosh]] also featured a flat file system, the [[Macintosh File System]]. It was unusual in that the file management program ([[Macintosh Finder]]) created the illusion of a partially hierarchical filing system on top of EMFS. This structure required every file to have a unique name, even if it appeared to be in a separate folder. [[IBM]] [[DOS/360]] and [[OS/360]] store entries for all files on a disk pack (''volume'') in a directory on the pack called a ''[[Volume Table of Contents]]'' (VTOC).

While simple, flat file systems become awkward as the number of files grows and makes it difficult to organize data into related groups of files.

A recent addition to the flat file system family is [[Amazon.com|Amazon]]'s [[Amazon S3|S3]], a remote storage service, which is intentionally simplistic to allow users the ability to customize how their data is stored. The only constructs are buckets (imagine a disk drive of unlimited size) and objects (similar, but not identical to the standard concept of a file). Advanced file management is allowed by being able to use nearly any character (including '/') in the object's name, and the ability to select subsets of the bucket's content based on identical prefixes.