The following tables compare general and technical information for a number of file systems. Please see the individual file system articles for further information.
General Information
Limits
Metadata
Features
Allocation and layout policies
Notes
Template:Fnb HFS, an older version of HFS+, only supported 31 character filenames; some older applications don't work well with names longer than this.
Template:Fnb HFS+ mandates support for an escape sequence to allow arbitrary Unicode. Users of older software might see the escape sequences instead of the desired characters.
Template:Fnb Varies wildly according to block size and fragmentation of block allocation groups.
Template:Fnb For filesystems that have variable allocation unit (block/cluster) sizes, a range of size are given, indicating the maximum volume sizes for the minimum and the maximum possible allocation unit sizes of the filesystem (e.g. 512 bytes and 128KiB for FAT — which is the cluster size range allowed by the on-disc data structures, although some Installable File System drivers and operating systems do not support cluster sizes larger than 32KiB).
Template:Fnb NTFS access control lists can express essentially any access policy possible using simple POSIX file permissions, but use of a POSIX-like interface is not supported without an add-on such as Services for UNIX or Cygwin.
Template:Fnb The file change logs, last entry change timestamps, and other filesystem metadata, are all part of the extensive suite of auditing capabilities built into NDS/eDirectory called NSure Audit. (Filesystem Events tracked by NSure)
Template:Fnb While FAT32 partitions this large work fine once created, some software won't allow creation of FAT32 partitions larger than 32GiB. This includes, notoriously, the Windows XP installation program.
Template:Fnb ReiserFS has a theoretical maximum file size of 1EiB, but "page cache limits this to 8 Ti on architectures with 32 bit int"[1]
Template:Fnb XFS has a limitation under Linux 2.4 of 64TiB file size and 2TiB file system size. This limitation is not present under IRIX.
Template:Fnb Microsoft first introduced FAT32 in Windows 95 OSR2 (OEM Service Release 2) and then later in Windows 98.
Template:Fnb IBM introduced JFS with the initial release of AIX Version 3.1 in 1990. This file system now called JFS1. The new JFS (sometimes called JFS2), on which the Linux port was based, was first shipped in OS/2 Warp Server for e-Business in 1999.
Template:Fnb The on-disc structures have no inherent limit. Particular Installable File System drivers and operating systems may impose limits of their own, however. MS-DOS does not support full pathnames longer than 260 bytes for FAT12 and FAT16. Windows NT does not support full pathnames longer than 32767 bytes for NTFS.
Template:Fnb This is the limit of the on-disc structures. The HPFS Installable File System driver for OS/2 uses the top 5 bits of the volume sector number for its own use, limiting the volume size that it can handle to 64GiB.
Template:Fnb The f-node contains a field for a user identifier. This is not used except by OS/2 Warp Server, however.
Template:Fnb Maximum combined filename/filetype length is 236 bytes; each component has an individual maximum length of 255 byes.
Template:Fnb Maximum pathname length is 4096 bytes, but quoted limits on individual components add up to 1664 bytes.
Template:Fnb Record Management Services (RMS) attributes include record type and size, among many others.
Template:Fnb These are referred to as "aliases".
Template:Fnb Novell calls this feature "multiple data streams". Published specifications say that NWFS allows for 16 attributes and 10 data streams, and NSS allows for unlimited quantities of both.
Template:Fnb Case-sensitivity/Preservation depends on client. Windows, DOS, and OS/2 clients don't see/keep case differences, whereas clients accessing via NFS or AFP may.
Template:Fnb Published specs say that the 128-bit file system provides for up to 264 bytes to describe the file system, file size, directory entries, etc, with a theoretical max of 2128 bytes total to describe all storage on such a machine.
Template:Fnb Particular Installable File System drivers and operating systems may not support extended attributes on FAT12, FAT16, and FAT32. The OS/2 and Windows NT filesystem drivers for FAT12, FAT16, and FAT32 support extended attributes (using a "EA DATA. SF" pseudo-file to reserve the clusters allocated to them). Other filesystem drivers for other operating systems do not.
Template:Fnb Some Installable File System drivers and operating systems may not support extended attributes, access control lists or security labels on these filesystems. Linux kernels prior to 2.6.x may either be missing support for these altogether or require a patch.
Template:Fnb Depends on whether the FAT12, FAT16, and FAT32 implementation has support for LFNs. Where it does not, as in OS/2, MS-DOS, Windows 95, Windows 98 in DOS-only mode and the Linux "msdos" driver, file names are limited to 11 8-bit characters (space padded in both the basename and extension parts) and may not contain NUL (end-of-directory marker) or character 229 (deleted-file marker). Short names also do not normally contain lowercase letters.
Template:Fnb These are the restrictions imposed by the on-disc directory entry structures themselves. Particular Installable File System drivers may place restrictions of their own on file and directory names; and particular and operating systems may also place restrictions of their own, across all filesystems. MS-DOS, Microsoft Windows, and OS/2 disallow the characters \ / : ? * " > < | and NUL in file and directory names across all filesystems. Unices and Linux disallow the characters / and NUL in file and directory names across all filesystems.
Template:Fnb In these filesystems the directory entries named "." and ".." have special status. Directory entries with these names are not prohibited, and indeed exist as normal directory entries in the on-disc data structures. However, they are mandatory directory entries, with mandatory values, that are automatically created in each directory when it is created; and directories without them are considered corrupt.
Template:Fnb The "." and ".." directory entries in HPFS that are seen by applications programs are a partial fiction created by the Installable File System drivers. The on-disc data structure for a directory does not contain entries by those names, but instead contains a special "start" entry. Whilst on-disc directory entries by those names are not physically prohibited, they cannot be created in normal operation, and a directory containing such entries is corrupt.
Template:Fnb NSS allows files to have multiple names, in separate namespaces.
Template:Fnb Some file and directory metadata is stored on the Netware server irrespective of whether Directory Services is installed or not, like date/time of creation, file size, purge status, etc; and some file and directory metadata is stored in NDS/eDirectory, like file/object permissions, ownership, etc.
Template:Fnb Particular Installable File System drivers and operating systems may not support case sensitivity for JFS. OS/2 does not, and Linux has a mount option for disabling case sensitivity.
Template:Fnb The local time, timezone/UTC offset, and date are derived from the time settings of the reference/single timesync source in the NDS tree.
Template:Fnb Some operating systems implemented extended attributes as a layer over UFS1 with a parallel backing file (e.g., FreeBSD 4.x).
Template:Fnb Access-control lists and MAC labels available as an operating-system feature layered on top of extended attributes.
Template:Fnb NTFS 5.0 and higher can create junctions, which allow entire directories (but not individual files) to be mapped to elsewhere in the directory tree of a locally managed drive. These are implemented through reparse points, which allow the normal process of filename resolution to be extended in a flexible manner.
Template:Fnb Turned off by default.
Template:Fnb While NTFS itself supports case sensitivity, the Windows standard file system drivers cannot create files whose names differ only by case, for compatibility reasons.
Template:Fnb NTFS stores everything, even the file data, as meta-data, so its log is closer to block journaling.
Template:Fnb UDF and LFS are log-structured file systems and behave as if the entire file system were a journal.
Template:Fnb In "extents" mode.
Template:Fnb Optionally no on IRIX.
Template:Fnb Variable block size refers to systems which support different block sizes on a per-file basis. (This is similar to extents but a slightly different implementational choice.) The current implementation in UFS2 is read-only.
Template:Fnb Block suballocation divides storage into blocks of 4KiB to 64KiB (usually 8KiB), and if all of the block is not used, the remainder is subdivided into 512-byte blocks for other files, usually smaller files, to use.
Template:Fnb This restriction might be lifted in newer versions.
Template:Fnb Full block journaling for ReiserFS was added to Linux 2.6.8.
Template:Fnb Other block:fragment size ratios supported; 8:1 is typical and recommended by most implementations.
Template:Fnb Depends on UDF implementation.
Template:Fnb Fragments were planned, but never actually implemented on ext2 and ext3.
Template:Fnb Metadata-only journaling was introduced in the Mac OS 10.2.2 HFS+ driver; journaling is enabled by default on Mac OS 10.3 and later.
Template:Fnb e2compr, a set of patches providing block-based compression for ext2, has been available since 1997, but has never been merged into the mainline Linux kernel.
Template:Fnb Reiser4 implements data compression, but has not provided an VFS API for it.
Template:Fnb DoubleSpace in DOS 6, and DriveSpace in Windows 95 and Windows 98 were data compression schemes for FAT, but are no longer supported by Microsoft.
Template:Fnb Some namespaces had lower name length limits. "LONG" had an 80-byte limit, "NTFS" 80 bytes, "NFS" 40 bytes and "DOS" imposed 8.3-style names.
Template:Fnb Available only in the "NFS" namespace.
Template:Fnb Metacomco released a so called "evolution" version of original file system for Amiga realizied by engineers of first Amiga Inc. (Formerly Hi-Toro) in 1982-83/85. To be true, Metacomco made a huge mess of early FS ruining its simple and easy structure. Originally OFS it was simply Amiga File System. Name changed since the release of the "new" Fast File System, born in 1987 for the same platform.
See also
References
External links