Note that in addition to the below table, block capabilities can be implemented below the file system layer in Linux (LVM, integritysetup, cryptsetup) or Windows (Volume Shadow Copy Service, SECURITY), etc.
While storage devices usually have their size expressed in powers of 10 (for instance a 1 TB Solid State Drive will contain at least 1,000,000,000,000 (1012, 10004) bytes), filesystem limits are invariably powers of 2, so usually expressed with IEC prefixes. For instance, a 1 TiB limit means 240, 10244 bytes. Approximations (rounding down) using power of 10 are also given below to clarify.
Shustek, Len (2016-08-02). "In His Own Words: Gary Kildall". Remarkable People. Computer History Museum. http://www.computerhistory.org/atchm/in-his-own-words-gary-kildall/
Kildall, Gary Arlen (2016-08-02) [1993]. Kildall, Scott; Kildall, Kristin (eds.). "Computer Connections: People, Places, and Events in the Evolution of the Personal Computer Industry" (Manuscript, part 1). Kildall Family. Retrieved 2016-11-17.
/wiki/Gary_Kildall
Mace, Scott (1986-09-22). "Extensions to MS-DOS Run CD-ROM". InfoWorld. 8 (38): 1, 8. Retrieved 2016-11-09. https://books.google.com/books?id=ZS8EAAAAMBAJ&pg=PA1
IBM introduced JFS with the initial release of AIX Version 3.1 in 1990. This file system now called JFS1. The new JFS, on which the Linux port was based, was first shipped in OS/2 Warp Server for e-Business in 1999. The same sourcebase was also used for release JFS2 on AIX 5L. /wiki/IBM_AIX
Warren, David (20 October 1993). "Polycenter File System - - HELP". Archived from the original on 9 March 2012. https://web.archive.org/web/20120309144054/http://www.ornl.gov/lists/mailing-lists/tru64-unix-managers/1993/10/msg00043.html
Microsoft first introduced FAT32 in MS-DOS 7.1 / Windows 95 OSR2 (OEM Service Release 2) and then later in Windows 98. NT-based Windows did not have any support for FAT32 up to Windows NT4; Windows 2000 was the first NT-based Windows OS that received the ability to work with it. /wiki/Microsoft
"Sun Microsystems Expands High Performance Computing Portfolio with Definitive Agreement to Acquire Assets of Cluster File Systems, Including the Lustre File System" (Press release). Santa Clara, Calif.: Sun Microsystems, Inc. 12 September 2007. Archived from the original on 2 October 2007. https://web.archive.org/web/20071002091821/http://www.sun.com/aboutsun/pr/2007-09/sunflash.20070912.2.xml
Matthew Dillon (2018-12-09). "hammer2/DESIGN". BSD Cross Reference. DragonFly BSD. Retrieved 2019-03-06. /wiki/Matthew_Dillon_(computer_scientist)
"Huawei announces the EROFS Linux file system intended for Android devices". XDA Developer. June 1, 2018. https://www.xda-developers.com/huawei-erofs-linux-file-system-android/
Implemented in later versions as an extension
"RT–11 Volume and File Formats Manual" (PDF). Digital Equipment Corporation. August 1991. pp. 1–26 .. 1–32. http://bitsavers.trailing-edge.com/pdf/dec/pdp11/rt11/v5.6_Aug91/AA-PD6PA-TC_RT-11_Volume_and_File_Formats_Manual_Aug91.pdf
"RT–11 Volume and File Formats Manual" (PDF). Digital Equipment Corporation. August 1991. pp. 1–4 .. 1–12. http://bitsavers.trailing-edge.com/pdf/dec/pdp11/rt11/v5.6_Aug91/AA-PD6PA-TC_RT-11_Volume_and_File_Formats_Manual_Aug91.pdf
"Format of the Unix 6 file system" (PDF). Archived from the original (PDF) on 2016-09-21. Retrieved 2016-02-21. https://web.archive.org/web/20160921012843/http://www.utdallas.edu/~venky/os/Proj/disk.pdf
See dinode structure on page 355 (FILESYS(5)) of "Unix Programmers Manual" (PDF) (Seventh ed.). Murray Hill, New Jersey: Bell Telephone Laboratories. January 1979. Retrieved 2016-02-21. http://web.cuzuco.com/~cuzuco/v7/v7vol1.pdf
Some FAT implementations, such as in Linux, show file modification timestamp (mtime) in the metadata change timestamp (ctime) field. This timestamp is however, not updated on file metadata change.
Particular Installable File System drivers and operating systems may not support extended attributes on FAT12 and FAT16. The OS/2 and Windows NT filesystem drivers for FAT12 and FAT16 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. /wiki/Installable_File_System
The f-node contains a field for a user identifier. This is not used except by OS/2 Warp Server, however. /wiki/OS/2
NTFS access control lists can express any access policy possible using simple POSIX file permissions (and far more), but use of a POSIX-like interface is not supported without an add-on such as Services for UNIX or Cygwin. /wiki/Access_control_list
As of Vista, NTFS has support for Mandatory Labels, which are used to enforce Mandatory Integrity Control.[12] /wiki/Mandatory_Integrity_Control
Initially, ReFS lacked support for ADS, but Server 2012 R2 and up add support for ADS on ReFS
Access-control lists and MAC labels are layered on top of extended attributes.
Access-control lists and MAC labels are layered on top of extended attributes.
Some operating systems implemented extended attributes as a layer over UFS1 with a parallel backing file (e.g., FreeBSD 4.x). /wiki/UFS1_(file_system)
Access-control lists and MAC labels are layered on top of extended attributes.
Access-control lists and MAC labels are layered on top of extended attributes.
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. /wiki/Installable_File_System
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. /wiki/Installable_File_System
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. /wiki/Installable_File_System
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. /wiki/Installable_File_System
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. /wiki/Installable_File_System
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. /wiki/Installable_File_System
Metadata is mostly checksummed,[13] however Direct/indirect/triple-indirect block maps are not protected by checksums[14]
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. /wiki/Installable_File_System
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. /wiki/Installable_File_System
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. /wiki/Installable_File_System
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. /wiki/Installable_File_System
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. /wiki/Installable_File_System
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. /wiki/Installable_File_System
Creation time stored since June 2015, xfsprogs version 3.2.3
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. /wiki/Installable_File_System
The local time, time zone/UTC offset, and date are derived from the time settings of the reference/single timesync source in the NDS tree. /wiki/UTC
The local time, time zone/UTC offset, and date are derived from the time settings of the reference/single timesync source in the NDS tree. /wiki/UTC
The local time, time zone/UTC offset, and date are derived from the time settings of the reference/single timesync source in the NDS tree. /wiki/UTC
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.
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. /wiki/Novell_Directory_Services
The local time, time zone/UTC offset, and date are derived from the time settings of the reference/single timesync source in the NDS tree. /wiki/UTC
The local time, time zone/UTC offset, and date are derived from the time settings of the reference/single timesync source in the NDS tree. /wiki/UTC
The local time, time zone/UTC offset, and date are derived from the time settings of the reference/single timesync source in the NDS tree. /wiki/UTC
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.
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. /wiki/Novell_Directory_Services
Record Management Services (RMS) attributes include record type and size, among many others.
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. /wiki/Installable_File_System
File permission in 9P are a variation of the traditional Unix permissions with some minor changes, e.g. the suid bit is replaced by a new 'exclusive access' bit. /wiki/9P_(protocol)
Supported on FreeBSD and Linux implementations, support may not be available on all operating systems.
Solaris "extended attributes" are really full-blown alternate data streams, in both the Solaris UFS and ZFS.
Access times are preserved from the original file system at creation time, but Rock Ridge file systems themselves are read-only.
libburnia can back up and restore ACLs with file system creation and extraction programs, but no kernel support exists. /wiki/Libburnia
libburnia can back up and restore extended attributes and MAC labels with file system creation and extraction programs, but no kernel support exists. /wiki/Libburnia
libburnia can back up and restore extended attributes and MAC labels with file system creation and extraction programs, but no kernel support exists. /wiki/Libburnia
System V Release 4, and some other Unix systems, retrofitted symbolic links to their versions of the Version 7 Unix file system, although the original version didn't support them. /wiki/Unix
Context based symlinks were supported in GFS, GFS2 only supports standard symlinks since the bind mount feature of the Linux VFS has made context based symlinks obsolete
Optional journaling of data
As of Windows Vista, NTFS fully supports symbolic links.[15] NTFS 3.0 (Windows 2000) and higher can create junctions, which allow entire directories (but not individual files) to be mapped to elsewhere in the directory tree of the same partition (file system). These are implemented through reparse points, which allow the normal process of filename resolution to be extended in a flexible manner.
NTFS stores everything, even the file data, as meta-data, so its log is closer to block journaling.
NTFS stores everything, even the file data, as meta-data, so its log is closer to block journaling.
While NTFS itself supports case sensitivity, the Win32 environment subsystem cannot create files whose names differ only by case for compatibility reasons. When a file is opened for writing, if there is any existing file whose name is a case-insensitive match for the new file, the existing file is truncated and opened for writing instead of a new file with a different name being created. Other subsystems like e. g. Services for Unix, that operate directly above the kernel and not on top of Win32 can have case-sensitivity. /wiki/Services_for_Unix
Siracusa, John (2011-07-20). "Mac OS X 10.7 Lion: the Ars Technica review". Ars Technica. Retrieved 14 December 2017. To keep track of hard links, HFS+ creates a separate file for each hard link inside a hidden directory at the root level of the volume. https://arstechnica.com/gadgets/2011/07/mac-os-x-10-7/12/#hfs-problems
Metadata-only journaling was introduced in the Mac OS X 10.2.2 HFS Plus driver; journaling is enabled by default on Mac OS X 10.3 and later.
Although often believed to be case sensitive, HFS Plus normally is not. The typical default installation is case-preserving only. From Mac OS X 10.3 on the command newfs_hfs -s will create a case-sensitive new file system.[17] HFS Plus version 5 optionally supports case-sensitivity. However, since case-sensitivity is fundamentally different from case-insensitivity, a new signature was required so existing HFS Plus utilities would not see case-sensitivity as a file system error that needed to be corrected. Since the new signature is 'HX', it is often believed this is a new filesystem instead of a simply an upgraded version of HFS Plus.[18][19]
Mac OS X Tiger (10.4) and late versions of Panther (10.3) provide file change logging (it's a feature of the file system software, not of the volume format, actually).[20]
"Soft dependencies" (softdep) in NetBSD, called "soft updates" in FreeBSD provide meta-data consistency at all times without double writes (journaling) /wiki/Soft_dependencies
McKusick, Marshall Kirk; Roberson, Jeff. "Journaled Soft-updates" (PDF). https://www.mckusick.com/softdep/suj.pdf
Journaled Soft Updates (SU+J) are the default as of FreeBSD 9.x-RELEASE [22][23]
UDF, LFS, and NILFS are log-structured file systems and behave as if the entire file system were a journal. /wiki/Log-structured_file_system
Linux kernel versions 2.6.12 and newer.
Off by default.
Off by default.
"EXT4 Case-Insensitive Directories/File-Name Lookups Coming With Linux 5.2". https://www.phoronix.com/scan.php?page=news_item&px=EXT4-Case-Insensitive-Linux-5.2
"2. High Level Design — The Linux Kernel documentation § 2.10. Inline Data". www.kernel.org. Retrieved 2022-12-24. https://www.kernel.org/doc/html/latest/filesystems/ext4/overview.html#inline-data
UDF, LFS, and NILFS are log-structured file systems and behave as if the entire file system were a journal. /wiki/Log-structured_file_system
Off by default.
UDF, LFS, and NILFS are log-structured file systems and behave as if the entire file system were a journal. /wiki/Log-structured_file_system
Full block journaling for ReiserFS was added to Linux 2.6.8.
Off by default.
Optionally no on IRIX and Linux.
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. /wiki/Installable_File_System
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.
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.
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.[26]
Available only in the "NFS" namespace.
Available only in the "NFS" namespace.
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.
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.
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.[26]
These are referred to as "aliases".
These are referred to as "aliases".
UDF, LFS, and NILFS are log-structured file systems and behave as if the entire file system were a journal. /wiki/Log-structured_file_system
UDF, LFS, and NILFS are log-structured file systems and behave as if the entire file system were a journal. /wiki/Log-structured_file_system
"Universal Disk Format Specification – Revision 2.60" (PDF). p. 34. This file, when small, can be embedded in the [Information Control Block] that describes it. http://www.osta.org/specs/pdf/udf260.pdf
ZFS is a transactional filesystem using copy-on-write semantics, guaranteeing an always-consistent on-disk state without the use of a traditional journal. However, it does also implement an intent log to provide better performance when synchronous writes are requested.
ZFS is a transactional filesystem using copy-on-write semantics, guaranteeing an always-consistent on-disk state without the use of a traditional journal. However, it does also implement an intent log to provide better performance when synchronous writes are requested.
"zpool-features.7 - OpenZFS documentation". openzfs.github.io. Retrieved 2024-09-23. https://openzfs.github.io/openzfs-docs/man/master/7/zpool-features.7.html#embedded_data
Btrfs is a transactional filesystem using copy-on-write semantics, guaranteeing an always-consistent on-disk state without the use of a traditional journal. It keeps track of last five transactions and uses checksums to find problematic drives, making write intent logs unnecessary.
Bcachefs is a transactional filesystem using copy-on-write semantics, guaranteeing an always-consistent on-disk state without the use of a traditional journal. Journal commits are fairly expensive operations as they require issuing FLUSH and FUA operations to the underlying devices. By default, a journal flush is issued one second after a filesystem update has been done, which primarily records btree updates ordered by when they occurred. This option may be useful on a personal workstation or laptop, and perhaps less appropriate on a server.
Since Windows 10 Enterprise Insider Preview build 19536
While NTFS itself supports case sensitivity, the Win32 environment subsystem cannot create files whose names differ only by case for compatibility reasons. When a file is opened for writing, if there is any existing file whose name is a case-insensitive match for the new file, the existing file is truncated and opened for writing instead of a new file with a different name being created. Other subsystems like e. g. Services for Unix, that operate directly above the kernel and not on top of Win32 can have case-sensitivity. /wiki/Services_for_Unix
A file system is self-healing if its capable to proactively autonomously detect and correct all but grave errors, faults and corruptions online both in internal metadata AND data. See US7694191B1 as example. This usually requires full checksumming as well as internal redundancy as well as corresponding logic.
"clonefile(2)". The cloned file dst shares its data blocks with the src file [..] http://www.manpagez.com/man/2/clonefile/
only inside of Stacker 3/4 and DriveSpace 3 compressed volumes[30] /wiki/Stacker_3
only inside of Stacker 3/4 and DriveSpace 3 compressed volumes[30] /wiki/Stacker_3
Supported only on Windows Server SKUs. However, partitions deduplicated on Server can be used on Client.
"About Data Deduplication". 31 May 2018. https://msdn.microsoft.com/en-us/library/hh769303(v=vs.85).aspx
HFS+ does not actually encrypt files: to implement FileVault, OS X creates an HFS+ filesystem in a sparse, encrypted disk image that is automatically mounted over the home directory when the user logs in. /wiki/FileVault
"Ext4 encryption". https://lwn.net/Articles/639427/
"Red Hat: What is bitrot?". https://www.redhat.com/en/blog/what-bit-rot-and-how-can-i-detect-it-rhel
"F2FS encryption". https://lwn.net/Articles/677620/
UDF, LFS, and NILFS are log-structured file systems and behave as if the entire file system were a journal. /wiki/Log-structured_file_system
Reiser4 supports transparent compression and encryption with the cryptcompress plugin which is the default file handler in version 4.1.
"mkfs.xfs(8) from xfsprogs 5.10.0-4". By default, mkfs.xfs [..] will enable the reflink [=deduplication] feature. https://manpages.debian.org/bullseye/xfsprogs/mkfs.xfs.8.en.html
"Red Hat: What is bitrot?". https://www.redhat.com/en/blog/what-bit-rot-and-how-can-i-detect-it-rhel
"JFS data compression". IBM. Retrieved 2020-07-26. https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/devicemanagement/jfsdatacomp.html
VxFS provides an optional feature called "Storage Checkpoints" which allows for advanced file system snapshots.
Applies to proprietary ZFS release 30 and ZFS On Linux. Encryption support is not yet available in all OpenZFS ports.[37][38][39] /wiki/OpenZFS
LZJB (optimized for performance while providing decent data compression)LZ4 (faster & higher ratio than lzjb)gzip levels: 1 (fastest) to 9 (best), default is 6zstd positive: 1 (fastest) to 19 (best), default is 3zstd negative: 1(best & default)-10, 20, 30, …, 100, 500, 1000(fastest)zle: compresses runs of zeros.[40] /wiki/LZJB
disabling copy-on-write (COW) to prevent fragmentation also disables data checksumming
zlib levels: 1 to 9, default is 3LZO (no levels) faster than ZLIB, worse ratiozstd levels: 1 to 15, default is 3 (higher levels are not available)[41] /wiki/Zlib
noneCRC-32C (default)crc64chacha20/poly1305 (When encryption is enabled. Encryption can only be specified for the entire filesystem, not per file or directory)[42] /wiki/Cyclic_redundancy_check#Standards_and_common_use
none (default)The three currently supported algorithms are gzip, LZ4, zstd.The compression level may also be optionally specified, as an integer between 0 and 15, e.g. lz4:15. 0 specifies the default compression level, 1 specifies the fastest and lowest compression ratio, and 15 the slowest and best compression ratio.[43] /wiki/Gzip
* 3.7: Added file-level snapshot (only available in Windows Server 2022).[44] /wiki/Windows_Server_2022
By using the per-file "integrity stream" that internally stores a checksum per cluster. Those per cluster checksums are not accessible so it is actually a per file feature and not a per block feature. Integrity streams are not enabled by default.[45]
* 3.9: Added post process compression with LZ4 and ZSTD and transparent decompression. /wiki/LZ4_(compression_algorithm)
By using the per-file "integrity stream" that internally stores a checksum per cluster. Those per cluster checksums are not accessible so it is actually a per file feature and not a per block feature. Integrity streams are not enabled by default.[45]
Some file system creation implementations reuse block references and support deduplication this way. This is not supported by the standard, but usually works well due to the file system's read-only nature.
Some file system creation implementations reuse block references and support deduplication this way. This is not supported by the standard, but usually works well due to the file system's read-only nature.
Some file system creation implementations reuse block references and support deduplication this way. This is not supported by the standard, but usually works well due to the file system's read-only nature.
A file system is self-healing if its capable to proactively autonomously detect and correct all but grave errors, faults and corruptions online both in internal metadata AND data. See US7694191B1 as example. This usually requires full checksumming as well as internal redundancy as well as corresponding logic.
With software based on GNU Parted. /wiki/GNU_Parted
With software based on GNU Parted. /wiki/GNU_Parted
With software based on GNU Parted. /wiki/GNU_Parted
With software based on GNU Parted. /wiki/GNU_Parted
"IBM's Journaled File System (JFS) for Linux". https://www.kernel.org/doc/Documentation/filesystems/jfs.txt
"Growing an XFS File System". https://docs.oracle.com/cd/E37670_01/E37355/html/ol_grow_xfs.html
"Shrinking Support - xfs.org". XFS Wiki. 2022-07-17. Archived from the original on 2022-07-17. Retrieved 2022-12-18. https://web.archive.org/web/20220717073119/http://xfs.org/index.php/Shrinking_Support
"Shrinking Support - xfs.org". XFS Wiki. 2022-07-17. Archived from the original on 2022-07-17. Retrieved 2022-12-18. https://web.archive.org/web/20220717073119/http://xfs.org/index.php/Shrinking_Support
"Frequently Asked Questions (Old Wiki)". Retrieved 5 May 2018. http://wiki.lustre.org/Frequently_Asked_Questions_(Old_Wiki)
"Kernel/Git/Jaegeuk/F2fs-tools.git - Userland tools for the f2fs filesystem". https://git.kernel.org/cgit/linux/kernel/git/jaegeuk/f2fs-tools.git/
"ntfsresize(8)". http://linux.die.net/man/8/ntfsresize
resize2fs(8) – Linux Programmer's Manual – Administration and Privileged Commands https://manned.org/resize2fs.8
resize2fs(8) – Linux Programmer's Manual – Administration and Privileged Commands https://manned.org/resize2fs.8
"Resizing File Systems". https://www.suse.com/documentation/sles11/stor_admin/data/biuymaa.html
"Resize reiserfs". Reiserfs wiki. https://reiser4.wiki.kernel.org/index.php/Resize_reiserfs
resize2fs(8) – Linux Programmer's Manual – Administration and Privileged Commands https://manned.org/resize2fs.8
"Just Enough Operating System (JeOS): Technical Information | SUSE". www.suse.com. Retrieved 28 April 2018. https://www.suse.com/products/server/technical-information/
Overstreet, Kent (18 Dec 2021). "bcachefs: Principles of Operation" (PDF). Retrieved 10 May 2023. https://bcachefs.org/bcachefs-principles-of-operation.pdf
"nilfs-resize(8)". http://nilfs.sourceforge.net/en/man8/nilfs-resize.8.html
Top-level vdevs can only be removed if the primary pool storage does not contain a top-level raidz vdev, all top-level vdevs have the same sector size, and the keys for all encrypted datasets are loaded. "MAN Pages zpool-remove.8". https://openzfs.github.io/openzfs-docs/man/master/8/zpool-remove.8.html
"Resizing and Growing Disks". https://www.freebsd.org/doc/handbook/disks-growing.html
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. /wiki/Extent_(file_systems)
"Mac users, meet APFS: macOS's new file system - ZDNet". ZDNet. https://www.zdnet.com/article/wwdc-2017-macoss-new-file-system/
"Apple File System Guide - FAQ". https://developer.apple.com/library/content/documentation/FileManagement/Conceptual/APFS_Guide/FAQ/FAQ.html
"CVF Region: MDFAT". http://www.techhelpmanual.com/808-cvf_region__mdfat.html
"DMSDOS CVF module" (dmsdoc.doc). 0.9.2.0. 1998-11-19. Archived from the original on 2016-11-02. Retrieved 2016-11-01. Usually all data for one cluster are stored in contiguous sectors, but if the filesystem is too fragmented there may not be a 'free hole' that is large enough for the data. […] Drivespace 3 and Stacker know a hack for that situation: they allow storing the data of one cluster in several fragments on the disk. http://cmp.felk.cvut.cz/~pisa/dmsdos/dmsdos.html
"Mapping DOS FAT to MDFAT". http://www.techhelpmanual.com/814-mapping_dos_fat_to_mdfat.html
"CVF Region: MDFAT". http://www.techhelpmanual.com/808-cvf_region__mdfat.html
"DMSDOS CVF module" (dmsdoc.doc). 0.9.2.0. 1998-11-19. Archived from the original on 2016-11-02. Retrieved 2016-11-01. Usually all data for one cluster are stored in contiguous sectors, but if the filesystem is too fragmented there may not be a 'free hole' that is large enough for the data. […] Drivespace 3 and Stacker know a hack for that situation: they allow storing the data of one cluster in several fragments on the disk. http://cmp.felk.cvut.cz/~pisa/dmsdos/dmsdos.html
"Mapping DOS FAT to MDFAT". http://www.techhelpmanual.com/814-mapping_dos_fat_to_mdfat.html
Only for "stuffed" inodes
Other block:fragment size ratios supported; 8:1 is typical and recommended by most implementations.
Other block:fragment size ratios supported; 8:1 is typical and recommended by most implementations.
Other block:fragment size ratios supported; 8:1 is typical and recommended by most implementations.
"[base] Revision 216796". https://svnweb.freebsd.org/base?view=revision&revision=216796
"Newfs(8)". https://www.freebsd.org/cgi/man.cgi?query=newfs&sektion=8&manpath=FreeBSD+8.4-RELEASE
Other block:fragment size ratios supported; 8:1 is typical and recommended by most implementations.
Fragments were planned, but never actually implemented on ext2 and ext3.
Fragments were planned, but never actually implemented on ext2 and ext3.
Fragments were planned, but never actually implemented on ext2 and ext3.
Stores one largest extent in disk, and caches multiple extents in DRAM dynamically.
Jaeguk Kim (2014-09-22). "[PATCH 2/3] f2fs: Introduce FITRIM in f2fs_ioctl". linux-kernel (Mailing list). https://lkml.org/lkml/2014/09/23/32
Tail packing is technically a special case of block suballocation where the suballocation unit size is always 1 byte.
Tail packing is technically a special case of block suballocation where the suballocation unit size is always 1 byte.
In "extents" mode.
"Reiser4 discard support". Reiser4 FS Wiki. https://reiser4.wiki.kernel.org/index.php/Reiser4_discard_support
"XFS Adds Shared Data Extents For Linux 4.9". https://www.phoronix.com/scan.php?page=news_item&px=XFS-Linux-4.9-Shared-Extents
Each possible size (in sectors) of file tail has a corresponding suballocation block chain in which all the tails of that size are stored. The overhead of managing suballocation block chains is usually less than the amount of block overhead saved by being able to increase the block size but the process is less efficient if there is not much free disk space.
Depends on UDF implementation.
ISO 9660 Level 3 only
ISO 9660 Level 3 only
ISO 9660 Level 3 only
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. /wiki/Extent_(file_systems)
Android Kernel File System Support (Documentation). Android Open Source Project. Retrieved 2023-01-11. https://source.android.com/docs/core/architecture/android-kernel-file-system-support
"GitHub - sgan81/Apfs-fuse: FUSE driver for APFS (Apple File System)". GitHub. 2020-01-18. https://github.com/sgan81/apfs-fuse
"APFS module for linux, with experimental write support. This tree is just for development, please use linux-apfs-oot instead.: Linux-apfs/Linux-apfs". GitHub. 2019-12-14. https://github.com/eafer/linux-apfs
Namjae Jeon (20 January 2020). "[PATCH v12 00/13] add the latest exfat driver". linux-kernel (Mailing list). Retrieved 18 December 2021. https://lkml.org/lkml/2020/1/20/420
"NTFS3 Pull Request acceptance". https://lkml.iu.edu/hypermail/linux/kernel/2109.0/03731.html
"Paragon HFS+ for Windows 10". http://www.paragon-software.com/home/hfs-windows/download.html
"Paragon HFS+ for Windows 10". http://www.paragon-software.com/home/hfs-windows/download.html
"Porting an Ancient Filesystem to Modern Linux". Time To Pull The Plug. Archived from the original on 2017-06-21. Retrieved 2016-04-22. https://web.archive.org/web/20170621190933/http://time.to.pullthepl.ug/blog/2013/6/24/porting-an-ancient-filesystem-to-modern-linux/
"A port of the xiafs filesystem to modern Linux kernels". Github (cdtk). 2019-06-28. https://github.com/ctdk/modern-xiafs
"Paragon ExtFS for Mac". https://www.paragon-software.com/ufsdhome/extfs-mac
"Explore2fs". chrysocome.net. http://www.chrysocome.net/explore2fs
"Paragon ExtFS for Windows". https://www.paragon-software.com/home/extfs-windows
"FAQ". Ext2 Installable File System For Windows. (Provides kernel level read/write access to Ext2 and Ext3 volumes in Windows NT4, 2000, XP and Vista.) http://www.fs-driver.org/faq.html
Branten, Bo. "Ext2Fsd Project: Open source ext3/4 file system driver for Windows (2K/XP/WIN7/WIN8)". Archived from the original on 2012-07-23. Retrieved 2012-07-24. https://web.archive.org/web/20120723091043/http://www.ext2fsd.com/
"Paragon ExtFS for Mac". https://www.paragon-software.com/ufsdhome/extfs-mac
"Explore2fs". chrysocome.net. http://www.chrysocome.net/explore2fs
"Paragon ExtFS for Windows". https://www.paragon-software.com/home/extfs-windows
"FAQ". Ext2 Installable File System For Windows. (Provides kernel level read/write access to Ext2 and Ext3 volumes in Windows NT4, 2000, XP and Vista.) http://www.fs-driver.org/faq.html
Branten, Bo. "Ext2Fsd Project: Open source ext3/4 file system driver for Windows (2K/XP/WIN7/WIN8)". Archived from the original on 2012-07-23. Retrieved 2012-07-24. https://web.archive.org/web/20120723091043/http://www.ext2fsd.com/
"FreeBSD Handbook". https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/filesystems-linux.html
"Paragon ExtFS for Mac". https://www.paragon-software.com/ufsdhome/extfs-mac
Hanselman, Scott (2021-11-02). "WSL2 can now mount Linux ext4 disks directly". Newsletter of Wonderful Things. Retrieved 2023-10-01. https://www.hanselman.com/blog/wsl2-can-now-mount-linux-ext4-disks-directly
Microsoft Corp. (2023-07-17). "Windows technical documentation: Windows development environment: Windows Subsystem for Linux". Microsoft Learn (published 2021-12-09). Archived from the original on 2021-12-27. Retrieved 2023-10-01. https://learn.microsoft.com/windows/wsl/basic-commands#mount-a-disk-or-device
"FreeBSD Handbook". https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/filesystems-linux.html
"Lustre Wiki". http://wiki.lustre.org/index.php?title=Main_Page
"FreeBSD 10.4 MAN page - reiserfs". www.freebsd.org. Retrieved 2019-08-05. https://www.freebsd.org/cgi/man.cgi?query=reiserfs&apropos=0&sektion=0&manpath=FreeBSD+10.4-RELEASE&arch=default&format=html
"FreeBSD 11 and Reiserfs". www.linuxquestions.org. 2016-12-19. Retrieved 2019-08-05. https://www.linuxquestions.org/questions/%2Absd-17/freebsd-11-and-reiserfs-4175595198/
"'svn commit: r300062 - in head/sys: gnu/fs modules modules/reiserfs' - MARC". marc.info. Retrieved 2019-08-05. https://marc.info/?l=freebsd-commits-all&m=146349940607224&w=2
"About Shared File Systems and the Linux Client - Sun QFS and Sun Storage Archive Manager 5.3 Installation Guide". Retrieved 2016-03-14. https://docs.oracle.com/cd/E22586_01/html/E22570/gledk.html
Supported using only EVMS; not currently supported using LVM
Provided in Plan 9 from User Space /wiki/Plan_9_from_User_Space
Provided in Plan 9 from User Space /wiki/Plan_9_from_User_Space
Provided in Plan 9 from User Space /wiki/Plan_9_from_User_Space
Provided in Plan 9 from User Space /wiki/Plan_9_from_User_Space
"ZFS Filesystem for FUSE/Linux". Wizy Wiki. 30 November 2009. Archived from the original on 13 May 2013. https://web.archive.org/web/20130513101601/http://www.wizy.org/wiki/ZFS_on_FUSE
"ZFS on Linux". Lawrence Livermore National Laboratory. http://zfsonlinux.org/
Kim, Arnold (4 October 2007). "Apple Seeds ZFS Read/Write Developer Preview 1.1 for Leopard". Mac Rumors. http://www.macrumors.com/2007/10/04/apple-seeds-zfs-read-write-developer-preview-1-1-for-leopard/
"OpenZFS on Windows". https://openzfsonwindows.org/
"WinBtrfs". Github (maharmstone). 2020-11-22. https://github.com/maharmstone/btrfs
"squashfs-tools". Freshports. http://www.freshports.org/sysutils/squashfs-tools/
"fusefs-squashfuse". Freshports. http://www.freshports.org/sysutils/fusefs-squashfuse/
FUSE based driver available that can eliminate need for iSCSI gateways or SMB shares, but the physical backend store BlueStore only runs on Linux.
Filesystem driver "Dokany" available that can eliminate need for iSCSI gateways or SMB shares, but the physical backend store BlueStore only runs on Linux.
FUSE based driver available that can eliminate need for iSCSI gateways or SMB shares, but the physical backend store BlueStore only runs on Linux.
These are the restrictions imposed by the on-disk directory entry structures themselves. Particular Installable File System drivers may place restrictions of their own on file and directory names; operating systems may also place restrictions of their own, across all filesystems. DOS, Windows, and OS/2 allow only the following characters from the current 8-bit OEM codepage in SFNs: A-Z, 0-9, characters ! # $ % & ' ( ) - @ ^ _ ` { } ~, as well as 0x80-0xFF and 0x20 (SPACE). Specifically, lowercase letters a-z, characters " * / : < > ? \ | + , . ; = [ ], control codes 0x00-0x1F, 0x7F and in some cases also 0xE5 are not allowed.) In LFNs, any UCS-2 Unicode except \ / : ? * " > < | and NUL are allowed in file and directory names across all filesystems. Unix-like systems disallow the characters / and NUL in file and directory names across all filesystems. /wiki/Installable_File_System
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 128 KiB (131.0 KB) for FAT — which is the cluster size range allowed by the on-disk data structures, although some Installable File System drivers and operating systems do not support cluster sizes larger than 32 KiB (32.76 KB)). /wiki/Kibibyte
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-disk 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.
The on-disk structures have no inherent limit. Particular Installable File System drivers and operating systems may impose limits of their own, however. Limited by its Current Directory Structure (CDS), DOS does not support more than 32 directory levels (except for DR DOS 3.31-6.0) or full pathnames longer than 66 bytes for FAT, or 255 characters for LFNs. Windows NT does not support full pathnames longer than 32,767 bytes for NTFS. Older POSIX APIs which rely on the PATH_MAX constant have a limit of 4,096 bytes on Linux but this can be worked around. Linux itself has no hard path length limits.[122][123] /wiki/Installable_File_System
"Frequently Asked Questions". https://developer.apple.com/library/archive/documentation/FileManagement/Conceptual/APFS_Guide/FAQ/FAQ.html
"Volume Format Comparison". https://developer.apple.com/library/archive/documentation/FileManagement/Conceptual/APFS_Guide/VolumeFormatComparison/VolumeFormatComparison.html
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-disk 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.
The on-disk structures have no inherent limit. Particular Installable File System drivers and operating systems may impose limits of their own, however. Limited by its Current Directory Structure (CDS), DOS does not support more than 32 directory levels (except for DR DOS 3.31-6.0) or full pathnames longer than 66 bytes for FAT, or 255 characters for LFNs. Windows NT does not support full pathnames longer than 32,767 bytes for NTFS. Older POSIX APIs which rely on the PATH_MAX constant have a limit of 4,096 bytes on Linux but this can be worked around. Linux itself has no hard path length limits.[122][123] /wiki/Installable_File_System
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-disk 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.
The on-disk structures have no inherent limit. Particular Installable File System drivers and operating systems may impose limits of their own, however. Limited by its Current Directory Structure (CDS), DOS does not support more than 32 directory levels (except for DR DOS 3.31-6.0) or full pathnames longer than 66 bytes for FAT, or 255 characters for LFNs. Windows NT does not support full pathnames longer than 32,767 bytes for NTFS. Older POSIX APIs which rely on the PATH_MAX constant have a limit of 4,096 bytes on Linux but this can be worked around. Linux itself has no hard path length limits.[122][123] /wiki/Installable_File_System
Varies wildly according to block size and fragmentation of block allocation groups.
"CephFS Maximum File Sizes and Performance". https://docs.ceph.com/en/mimic/cephfs/administration/
"CephFS Directory Fragmentation". https://docs.ceph.com/en/latest/cephfs/dirfrags/
"ExFAT: File Name Directory Entry". https://www.ntfs.com/exfat-filename-dentry.htm
"File System Functionality Comparison". Microsoft Docs. Microsoft. 2021-01-07. Retrieved 2022-08-14. https://docs.microsoft.com/en-us/windows/win32/fileio/filesystem-functionality-comparison?redirectedfrom=MSDN#limits
"File System Functionality Comparison". Microsoft Docs. Microsoft. 2021-01-07. Retrieved 2022-08-14. https://docs.microsoft.com/en-us/windows/win32/fileio/filesystem-functionality-comparison?redirectedfrom=MSDN#limits
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-disk 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.
The on-disk structures have no inherent limit. Particular Installable File System drivers and operating systems may impose limits of their own, however. Limited by its Current Directory Structure (CDS), DOS does not support more than 32 directory levels (except for DR DOS 3.31-6.0) or full pathnames longer than 66 bytes for FAT, or 255 characters for LFNs. Windows NT does not support full pathnames longer than 32,767 bytes for NTFS. Older POSIX APIs which rely on the PATH_MAX constant have a limit of 4,096 bytes on Linux but this can be worked around. Linux itself has no hard path length limits.[122][123] /wiki/Installable_File_System
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-disk 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.
The on-disk structures have no inherent limit. Particular Installable File System drivers and operating systems may impose limits of their own, however. Limited by its Current Directory Structure (CDS), DOS does not support more than 32 directory levels (except for DR DOS 3.31-6.0) or full pathnames longer than 66 bytes for FAT, or 255 characters for LFNs. Windows NT does not support full pathnames longer than 32,767 bytes for NTFS. Older POSIX APIs which rely on the PATH_MAX constant have a limit of 4,096 bytes on Linux but this can be worked around. Linux itself has no hard path length limits.[122][123] /wiki/Installable_File_System
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 128 KiB (131.0 KB) for FAT — which is the cluster size range allowed by the on-disk data structures, although some Installable File System drivers and operating systems do not support cluster sizes larger than 32 KiB (32.76 KB)). /wiki/Kibibyte
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-disk 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.
The on-disk structures have no inherent limit. Particular Installable File System drivers and operating systems may impose limits of their own, however. Limited by its Current Directory Structure (CDS), DOS does not support more than 32 directory levels (except for DR DOS 3.31-6.0) or full pathnames longer than 66 bytes for FAT, or 255 characters for LFNs. Windows NT does not support full pathnames longer than 32,767 bytes for NTFS. Older POSIX APIs which rely on the PATH_MAX constant have a limit of 4,096 bytes on Linux but this can be worked around. Linux itself has no hard path length limits.[122][123] /wiki/Installable_File_System
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 128 KiB (131.0 KB) for FAT — which is the cluster size range allowed by the on-disk data structures, although some Installable File System drivers and operating systems do not support cluster sizes larger than 32 KiB (32.76 KB)). /wiki/Kibibyte
Vimal A.R (16 July 2016). "Max file-name length in an EXT4 file system". arvimal.blog. Archived from the original on 28 February 2021. https://web.archive.org/web/20210228121426/https://arvimal.blog/2016/07/21/max-file-name-length-in-an-ext4-file-system/
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-disk 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.
The on-disk structures have no inherent limit. Particular Installable File System drivers and operating systems may impose limits of their own, however. Limited by its Current Directory Structure (CDS), DOS does not support more than 32 directory levels (except for DR DOS 3.31-6.0) or full pathnames longer than 66 bytes for FAT, or 255 characters for LFNs. Windows NT does not support full pathnames longer than 32,767 bytes for NTFS. Older POSIX APIs which rely on the PATH_MAX constant have a limit of 4,096 bytes on Linux but this can be worked around. Linux itself has no hard path length limits.[122][123] /wiki/Installable_File_System
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 128 KiB (131.0 KB) for FAT — which is the cluster size range allowed by the on-disk data structures, although some Installable File System drivers and operating systems do not support cluster sizes larger than 32 KiB (32.76 KB)). /wiki/Kibibyte
"Interviews/EricSandeen". Fedora Project Wiki. 9 June 2008. https://fedoraproject.org/wiki/Interviews/EricSandeen
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-disk 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.
The on-disk structures have no inherent limit. Particular Installable File System drivers and operating systems may impose limits of their own, however. Limited by its Current Directory Structure (CDS), DOS does not support more than 32 directory levels (except for DR DOS 3.31-6.0) or full pathnames longer than 66 bytes for FAT, or 255 characters for LFNs. Windows NT does not support full pathnames longer than 32,767 bytes for NTFS. Older POSIX APIs which rely on the PATH_MAX constant have a limit of 4,096 bytes on Linux but this can be worked around. Linux itself has no hard path length limits.[122][123] /wiki/Installable_File_System
Depends on whether the FAT12, FAT16, and FAT32 implementation has support for LFNs. Where it does not, as in OS/2, DOS, Windows 95, Windows 98 in DOS-only mode and the Linux "msdos" driver, file names are limited to 8.3 format of 8-bit OEM characters (space padded in both the basename and extension parts) and may not contain NUL (end-of-directory marker) or character 5 (replacement for character 229 which itself is used as deleted-file marker). Short names also must not contain lowercase letters. A few special device names (CON, NUL, AUX, PRN, LPT1, COM1, etc.) should be avoided, as some operating systems (notably DOS, OS/2 and Windows) reserve them. /wiki/FAT12
These are the restrictions imposed by the on-disk directory entry structures themselves. Particular Installable File System drivers may place restrictions of their own on file and directory names; operating systems may also place restrictions of their own, across all filesystems. DOS, Windows, and OS/2 allow only the following characters from the current 8-bit OEM codepage in SFNs: A-Z, 0-9, characters ! # $ % & ' ( ) - @ ^ _ ` { } ~, as well as 0x80-0xFF and 0x20 (SPACE). Specifically, lowercase letters a-z, characters " * / : < > ? \ | + , . ; = [ ], control codes 0x00-0x1F, 0x7F and in some cases also 0xE5 are not allowed.) In LFNs, any UCS-2 Unicode except \ / : ? * " > < | and NUL are allowed in file and directory names across all filesystems. Unix-like systems disallow the characters / and NUL in file and directory names across all filesystems. /wiki/Installable_File_System
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-disk 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.
The on-disk structures have no inherent limit. Particular Installable File System drivers and operating systems may impose limits of their own, however. Limited by its Current Directory Structure (CDS), DOS does not support more than 32 directory levels (except for DR DOS 3.31-6.0) or full pathnames longer than 66 bytes for FAT, or 255 characters for LFNs. Windows NT does not support full pathnames longer than 32,767 bytes for NTFS. Older POSIX APIs which rely on the PATH_MAX constant have a limit of 4,096 bytes on Linux but this can be worked around. Linux itself has no hard path length limits.[122][123] /wiki/Installable_File_System
On-disk structures would support up to 4 GiB (4.294 GB), but practical file size is limited by volume size. /wiki/Gibibyte
Depends on whether the FAT12, FAT16, and FAT32 implementation has support for LFNs. Where it does not, as in OS/2, DOS, Windows 95, Windows 98 in DOS-only mode and the Linux "msdos" driver, file names are limited to 8.3 format of 8-bit OEM characters (space padded in both the basename and extension parts) and may not contain NUL (end-of-directory marker) or character 5 (replacement for character 229 which itself is used as deleted-file marker). Short names also must not contain lowercase letters. A few special device names (CON, NUL, AUX, PRN, LPT1, COM1, etc.) should be avoided, as some operating systems (notably DOS, OS/2 and Windows) reserve them. /wiki/FAT12
These are the restrictions imposed by the on-disk directory entry structures themselves. Particular Installable File System drivers may place restrictions of their own on file and directory names; operating systems may also place restrictions of their own, across all filesystems. DOS, Windows, and OS/2 allow only the following characters from the current 8-bit OEM codepage in SFNs: A-Z, 0-9, characters ! # $ % & ' ( ) - @ ^ _ ` { } ~, as well as 0x80-0xFF and 0x20 (SPACE). Specifically, lowercase letters a-z, characters " * / : < > ? \ | + , . ; = [ ], control codes 0x00-0x1F, 0x7F and in some cases also 0xE5 are not allowed.) In LFNs, any UCS-2 Unicode except \ / : ? * " > < | and NUL are allowed in file and directory names across all filesystems. Unix-like systems disallow the characters / and NUL in file and directory names across all filesystems. /wiki/Installable_File_System
Depends on whether the FAT12, FAT16, and FAT32 implementation has support for LFNs. Where it does not, as in OS/2, DOS, Windows 95, Windows 98 in DOS-only mode and the Linux "msdos" driver, file names are limited to 8.3 format of 8-bit OEM characters (space padded in both the basename and extension parts) and may not contain NUL (end-of-directory marker) or character 5 (replacement for character 229 which itself is used as deleted-file marker). Short names also must not contain lowercase letters. A few special device names (CON, NUL, AUX, PRN, LPT1, COM1, etc.) should be avoided, as some operating systems (notably DOS, OS/2 and Windows) reserve them. /wiki/FAT12
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-disk 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.
The on-disk structures have no inherent limit. Particular Installable File System drivers and operating systems may impose limits of their own, however. Limited by its Current Directory Structure (CDS), DOS does not support more than 32 directory levels (except for DR DOS 3.31-6.0) or full pathnames longer than 66 bytes for FAT, or 255 characters for LFNs. Windows NT does not support full pathnames longer than 32,767 bytes for NTFS. Older POSIX APIs which rely on the PATH_MAX constant have a limit of 4,096 bytes on Linux but this can be worked around. Linux itself has no hard path length limits.[122][123] /wiki/Installable_File_System
On-disk structures would support up to 4 GiB (4.294 GB), but practical file size is limited by volume size. /wiki/Gibibyte
Depends on whether the FAT12, FAT16, and FAT32 implementation has support for LFNs. Where it does not, as in OS/2, DOS, Windows 95, Windows 98 in DOS-only mode and the Linux "msdos" driver, file names are limited to 8.3 format of 8-bit OEM characters (space padded in both the basename and extension parts) and may not contain NUL (end-of-directory marker) or character 5 (replacement for character 229 which itself is used as deleted-file marker). Short names also must not contain lowercase letters. A few special device names (CON, NUL, AUX, PRN, LPT1, COM1, etc.) should be avoided, as some operating systems (notably DOS, OS/2 and Windows) reserve them. /wiki/FAT12
These are the restrictions imposed by the on-disk directory entry structures themselves. Particular Installable File System drivers may place restrictions of their own on file and directory names; operating systems may also place restrictions of their own, across all filesystems. DOS, Windows, and OS/2 allow only the following characters from the current 8-bit OEM codepage in SFNs: A-Z, 0-9, characters ! # $ % & ' ( ) - @ ^ _ ` { } ~, as well as 0x80-0xFF and 0x20 (SPACE). Specifically, lowercase letters a-z, characters " * / : < > ? \ | + , . ; = [ ], control codes 0x00-0x1F, 0x7F and in some cases also 0xE5 are not allowed.) In LFNs, any UCS-2 Unicode except \ / : ? * " > < | and NUL are allowed in file and directory names across all filesystems. Unix-like systems disallow the characters / and NUL in file and directory names across all filesystems. /wiki/Installable_File_System
Depends on whether the FAT12, FAT16, and FAT32 implementation has support for LFNs. Where it does not, as in OS/2, DOS, Windows 95, Windows 98 in DOS-only mode and the Linux "msdos" driver, file names are limited to 8.3 format of 8-bit OEM characters (space padded in both the basename and extension parts) and may not contain NUL (end-of-directory marker) or character 5 (replacement for character 229 which itself is used as deleted-file marker). Short names also must not contain lowercase letters. A few special device names (CON, NUL, AUX, PRN, LPT1, COM1, etc.) should be avoided, as some operating systems (notably DOS, OS/2 and Windows) reserve them. /wiki/FAT12
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-disk 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.
"File System Functionality Comparison". Microsoft Docs. Microsoft. 2021-01-07. Retrieved 2022-08-14. https://docs.microsoft.com/en-us/windows/win32/fileio/filesystem-functionality-comparison?redirectedfrom=MSDN#limits
"File System Functionality Comparison". Microsoft Docs. Microsoft. 2021-01-07. Retrieved 2022-08-14. https://docs.microsoft.com/en-us/windows/win32/fileio/filesystem-functionality-comparison?redirectedfrom=MSDN#limits
While FAT32 partitions this large work fine once created, some software won't allow creation of FAT32 partitions larger than 32 GiB (34.35 GB). This includes, notoriously, the Windows XP installation program and the Disk Management console in Windows 2000, XP, 2003 and Vista. Use FDISK from a Windows ME Emergency Boot Disk to avoid.[104] /wiki/Partition_(computing)
Depends on whether the FAT12, FAT16, and FAT32 implementation has support for LFNs. Where it does not, as in OS/2, DOS, Windows 95, Windows 98 in DOS-only mode and the Linux "msdos" driver, file names are limited to 8.3 format of 8-bit OEM characters (space padded in both the basename and extension parts) and may not contain NUL (end-of-directory marker) or character 5 (replacement for character 229 which itself is used as deleted-file marker). Short names also must not contain lowercase letters. A few special device names (CON, NUL, AUX, PRN, LPT1, COM1, etc.) should be avoided, as some operating systems (notably DOS, OS/2 and Windows) reserve them. /wiki/FAT12
The on-disk structures have no inherent limit. Particular Installable File System drivers and operating systems may impose limits of their own, however. Limited by its Current Directory Structure (CDS), DOS does not support more than 32 directory levels (except for DR DOS 3.31-6.0) or full pathnames longer than 66 bytes for FAT, or 255 characters for LFNs. Windows NT does not support full pathnames longer than 32,767 bytes for NTFS. Older POSIX APIs which rely on the PATH_MAX constant have a limit of 4,096 bytes on Linux but this can be worked around. Linux itself has no hard path length limits.[122][123] /wiki/Installable_File_System
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-disk 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.
The on-disk structures have no inherent limit. Particular Installable File System drivers and operating systems may impose limits of their own, however. Limited by its Current Directory Structure (CDS), DOS does not support more than 32 directory levels (except for DR DOS 3.31-6.0) or full pathnames longer than 66 bytes for FAT, or 255 characters for LFNs. Windows NT does not support full pathnames longer than 32,767 bytes for NTFS. Older POSIX APIs which rely on the PATH_MAX constant have a limit of 4,096 bytes on Linux but this can be worked around. Linux itself has no hard path length limits.[122][123] /wiki/Installable_File_System
"GEMDOS Overview". http://cd.textfiles.com/ataricompendium/BOOK/HTML/CHAP2.HTM
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-disk 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.
The on-disk structures have no inherent limit. Particular Installable File System drivers and operating systems may impose limits of their own, however. Limited by its Current Directory Structure (CDS), DOS does not support more than 32 directory levels (except for DR DOS 3.31-6.0) or full pathnames longer than 66 bytes for FAT, or 255 characters for LFNs. Windows NT does not support full pathnames longer than 32,767 bytes for NTFS. Older POSIX APIs which rely on the PATH_MAX constant have a limit of 4,096 bytes on Linux but this can be worked around. Linux itself has no hard path length limits.[122][123] /wiki/Installable_File_System
Depends on CPU arch. For 32bit kernels the max is 16 TiB (17.59 TB). [106]
Depends on CPU arch. For 32bit kernels the max is 16 TiB (17.59 TB). [107]
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-disk 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.
The on-disk structures have no inherent limit. Particular Installable File System drivers and operating systems may impose limits of their own, however. Limited by its Current Directory Structure (CDS), DOS does not support more than 32 directory levels (except for DR DOS 3.31-6.0) or full pathnames longer than 66 bytes for FAT, or 255 characters for LFNs. Windows NT does not support full pathnames longer than 32,767 bytes for NTFS. Older POSIX APIs which rely on the PATH_MAX constant have a limit of 4,096 bytes on Linux but this can be worked around. Linux itself has no hard path length limits.[122][123] /wiki/Installable_File_System
Depends on kernel version and arch. For 2.4 kernels the max is 2 TiB (2.199 TB). For 32-bit 2.6 kernels it is 16 TiB (17.59 TB). For 64-bit 2.6 kernels it is 8 EiB (9.223 EB).
Depends on kernel version and arch. For 2.4 kernels the max is 2 TiB (2.199 TB). For 32-bit 2.6 kernels it is 16 TiB (17.59 TB). For 64-bit 2.6 kernels it is 8 EiB (9.223 EB).
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-disk 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.
The on-disk structures have no inherent limit. Particular Installable File System drivers and operating systems may impose limits of their own, however. Limited by its Current Directory Structure (CDS), DOS does not support more than 32 directory levels (except for DR DOS 3.31-6.0) or full pathnames longer than 66 bytes for FAT, or 255 characters for LFNs. Windows NT does not support full pathnames longer than 32,767 bytes for NTFS. Older POSIX APIs which rely on the PATH_MAX constant have a limit of 4,096 bytes on Linux but this can be worked around. Linux itself has no hard path length limits.[122][123] /wiki/Installable_File_System
Matthew Dillon. "HAMMER2 Design Document". we can allow filenames up to 1023 bytes long http://apollo.backplane.com/DFlyMisc/hammer2.txt
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-disk 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.
Matthew Dillon (June 21, 2008). "The HAMMER Filesystem" (PDF). http://www.dragonflybsd.org/hammer/hammer.pdf
The "classic" Mac OS provides two sets of functions to retrieve file names from an HFS Plus volume, one of them returning the full Unicode names, the other shortened names fitting in the older 31 byte limit to accommodate older applications.
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-disk 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.
HFS Plus mandates support for an escape sequence to allow arbitrary Unicode. Users of older software might see the escape sequences instead of the desired characters. /wiki/Escape_sequence
"Mac OS X: Mac OS Extended format (HFS Plus) volume and file limits". support.apple.com. July 26, 2016. Archived from the original on 2019-04-08. https://web.archive.org/web/20190408213105/https://support.apple.com/en-us/HT201711
"Mac OS 8, 9: Mac OS Extended Format - Volume and File Limits". support.apple.com. February 20, 2012. https://support.apple.com/kb/TA21924
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-disk data structure for a directory does not contain entries by those names, but instead contains a special "start" entry. Whilst on-disk directory entries by those names are not physically prohibited, they cannot be created in normal operation, and a directory containing such entries is corrupt. /wiki/Installable_File_System
The on-disk structures have no inherent limit. Particular Installable File System drivers and operating systems may impose limits of their own, however. Limited by its Current Directory Structure (CDS), DOS does not support more than 32 directory levels (except for DR DOS 3.31-6.0) or full pathnames longer than 66 bytes for FAT, or 255 characters for LFNs. Windows NT does not support full pathnames longer than 32,767 bytes for NTFS. Older POSIX APIs which rely on the PATH_MAX constant have a limit of 4,096 bytes on Linux but this can be worked around. Linux itself has no hard path length limits.[122][123] /wiki/Installable_File_System
This is the limit of the on-disk 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 64 GiB (68.71 GB). /wiki/Installable_File_System
"SFS file system". www.ibm.com. 2015-06-03. Archived from the original on 2022-09-13. Retrieved 2022-09-13. https://www.ibm.com/docs/en/cobol-aix/5.1?topic=systems-sfs-file-system
ISO 9660#Restrictions /wiki/ISO_9660#Restrictions
Through the use of multi-extents, a file can consist of multiple segments, each up to 4 GiB (4.294 GB) in size. See ISO 9660#The 2 GiB (2.147 GB) (or 4 GiB (4.294 GB) depending on implementation) file size limit /wiki/Gibibyte
Assuming the typical 2048 Byte sector size. The volume size is specified as a 32 bit value identifying the number of sectors on the volume.
The on-disk structures have no inherent limit. Particular Installable File System drivers and operating systems may impose limits of their own, however. Limited by its Current Directory Structure (CDS), DOS does not support more than 32 directory levels (except for DR DOS 3.31-6.0) or full pathnames longer than 66 bytes for FAT, or 255 characters for LFNs. Windows NT does not support full pathnames longer than 32,767 bytes for NTFS. Older POSIX APIs which rely on the PATH_MAX constant have a limit of 4,096 bytes on Linux but this can be worked around. Linux itself has no hard path length limits.[122][123] /wiki/Installable_File_System
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-disk 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.
The on-disk structures have no inherent limit. Particular Installable File System drivers and operating systems may impose limits of their own, however. Limited by its Current Directory Structure (CDS), DOS does not support more than 32 directory levels (except for DR DOS 3.31-6.0) or full pathnames longer than 66 bytes for FAT, or 255 characters for LFNs. Windows NT does not support full pathnames longer than 32,767 bytes for NTFS. Older POSIX APIs which rely on the PATH_MAX constant have a limit of 4,096 bytes on Linux but this can be worked around. Linux itself has no hard path length limits.[122][123] /wiki/Installable_File_System
"Joliet Specification". 22 May 1995. Archived from the original on 14 April 2009. https://web.archive.org/web/20090414104421/http://bmrc.berkeley.edu/people/chaffee/jolspec.html
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-disk 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.
The on-disk structures have no inherent limit. Particular Installable File System drivers and operating systems may impose limits of their own, however. Limited by its Current Directory Structure (CDS), DOS does not support more than 32 directory levels (except for DR DOS 3.31-6.0) or full pathnames longer than 66 bytes for FAT, or 255 characters for LFNs. Windows NT does not support full pathnames longer than 32,767 bytes for NTFS. Older POSIX APIs which rely on the PATH_MAX constant have a limit of 4,096 bytes on Linux but this can be worked around. Linux itself has no hard path length limits.[122][123] /wiki/Installable_File_System
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-disk 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.
The on-disk structures have no inherent limit. Particular Installable File System drivers and operating systems may impose limits of their own, however. Limited by its Current Directory Structure (CDS), DOS does not support more than 32 directory levels (except for DR DOS 3.31-6.0) or full pathnames longer than 66 bytes for FAT, or 255 characters for LFNs. Windows NT does not support full pathnames longer than 32,767 bytes for NTFS. Older POSIX APIs which rely on the PATH_MAX constant have a limit of 4,096 bytes on Linux but this can be worked around. Linux itself has no hard path length limits.[122][123] /wiki/Installable_File_System
Sparse files can be larger than the file system size, even though they can't contain more data.
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-disk 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.
The on-disk structures have no inherent limit. Particular Installable File System drivers and operating systems may impose limits of their own, however. Limited by its Current Directory Structure (CDS), DOS does not support more than 32 directory levels (except for DR DOS 3.31-6.0) or full pathnames longer than 66 bytes for FAT, or 255 characters for LFNs. Windows NT does not support full pathnames longer than 32,767 bytes for NTFS. Older POSIX APIs which rely on the PATH_MAX constant have a limit of 4,096 bytes on Linux but this can be worked around. Linux itself has no hard path length limits.[122][123] /wiki/Installable_File_System
Sparse files can be larger than the file system size, even though they can't contain more data.
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-disk 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.
The on-disk structures have no inherent limit. Particular Installable File System drivers and operating systems may impose limits of their own, however. Limited by its Current Directory Structure (CDS), DOS does not support more than 32 directory levels (except for DR DOS 3.31-6.0) or full pathnames longer than 66 bytes for FAT, or 255 characters for LFNs. Windows NT does not support full pathnames longer than 32,767 bytes for NTFS. Older POSIX APIs which rely on the PATH_MAX constant have a limit of 4,096 bytes on Linux but this can be worked around. Linux itself has no hard path length limits.[122][123] /wiki/Installable_File_System
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-disk 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.
The on-disk structures have no inherent limit. Particular Installable File System drivers and operating systems may impose limits of their own, however. Limited by its Current Directory Structure (CDS), DOS does not support more than 32 directory levels (except for DR DOS 3.31-6.0) or full pathnames longer than 66 bytes for FAT, or 255 characters for LFNs. Windows NT does not support full pathnames longer than 32,767 bytes for NTFS. Older POSIX APIs which rely on the PATH_MAX constant have a limit of 4,096 bytes on Linux but this can be worked around. Linux itself has no hard path length limits.[122][123] /wiki/Installable_File_System
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-disk 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.
The on-disk structures have no inherent limit. Particular Installable File System drivers and operating systems may impose limits of their own, however. Limited by its Current Directory Structure (CDS), DOS does not support more than 32 directory levels (except for DR DOS 3.31-6.0) or full pathnames longer than 66 bytes for FAT, or 255 characters for LFNs. Windows NT does not support full pathnames longer than 32,767 bytes for NTFS. Older POSIX APIs which rely on the PATH_MAX constant have a limit of 4,096 bytes on Linux but this can be worked around. Linux itself has no hard path length limits.[122][123] /wiki/Installable_File_System
NSS allows files to have multiple names, in separate namespaces.
Russon, Richard; Fledel, Yuval. "NTFS Documentation" (PDF). http://dubeyko.com/development/FileSystems/NTFS/ntfsdoc.pdf
The on-disk structures have no inherent limit. Particular Installable File System drivers and operating systems may impose limits of their own, however. Limited by its Current Directory Structure (CDS), DOS does not support more than 32 directory levels (except for DR DOS 3.31-6.0) or full pathnames longer than 66 bytes for FAT, or 255 characters for LFNs. Windows NT does not support full pathnames longer than 32,767 bytes for NTFS. Older POSIX APIs which rely on the PATH_MAX constant have a limit of 4,096 bytes on Linux but this can be worked around. Linux itself has no hard path length limits.[122][123] /wiki/Installable_File_System
This is the limit of the on-disk structures. The NTFS driver for Windows NT limits the volume size that it can handle to 256 TiB (281.4 TB) and the file size to 16 TiB (17.59 TB) respectively; in Windows 10 version 1709, the limit is 8 PiB (9.007 PB) when using 2 MiB (2.097 MB) cluster size. /wiki/Windows_NT
"NTFS overview". Microsoft Docs. 2022-05-26. Archived from the original on 2022-05-26. Retrieved 2022-06-05. https://docs.microsoft.com/en-us/windows-server/storage/file-server/ntfs-overview
This is the limit of the on-disk structures. The NTFS driver for Windows NT limits the volume size that it can handle to 256 TiB (281.4 TB) and the file size to 16 TiB (17.59 TB) respectively; in Windows 10 version 1709, the limit is 8 PiB (9.007 PB) when using 2 MiB (2.097 MB) cluster size. /wiki/Windows_NT
"NTFS overview". Microsoft Docs. 2022-05-26. Archived from the original on 2022-05-26. Retrieved 2022-06-05. https://docs.microsoft.com/en-us/windows-server/storage/file-server/ntfs-overview
Some namespaces had lower name length limits. "LONG" had an 80-byte limit, "NWFS" 80 bytes, "NFS" 40 bytes and "DOS" imposed 8.3 filename. /wiki/8.3_filename
NSS allows files to have multiple names, in separate namespaces.
The on-disk structures have no inherent limit. Particular Installable File System drivers and operating systems may impose limits of their own, however. Limited by its Current Directory Structure (CDS), DOS does not support more than 32 directory levels (except for DR DOS 3.31-6.0) or full pathnames longer than 66 bytes for FAT, or 255 characters for LFNs. Windows NT does not support full pathnames longer than 32,767 bytes for NTFS. Older POSIX APIs which rely on the PATH_MAX constant have a limit of 4,096 bytes on Linux but this can be worked around. Linux itself has no hard path length limits.[122][123] /wiki/Installable_File_System
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-disk 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.
The on-disk structures have no inherent limit. Particular Installable File System drivers and operating systems may impose limits of their own, however. Limited by its Current Directory Structure (CDS), DOS does not support more than 32 directory levels (except for DR DOS 3.31-6.0) or full pathnames longer than 66 bytes for FAT, or 255 characters for LFNs. Windows NT does not support full pathnames longer than 32,767 bytes for NTFS. Older POSIX APIs which rely on the PATH_MAX constant have a limit of 4,096 bytes on Linux but this can be worked around. Linux itself has no hard path length limits.[122][123] /wiki/Installable_File_System
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-disk 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.
The on-disk structures have no inherent limit. Particular Installable File System drivers and operating systems may impose limits of their own, however. Limited by its Current Directory Structure (CDS), DOS does not support more than 32 directory levels (except for DR DOS 3.31-6.0) or full pathnames longer than 66 bytes for FAT, or 255 characters for LFNs. Windows NT does not support full pathnames longer than 32,767 bytes for NTFS. Older POSIX APIs which rely on the PATH_MAX constant have a limit of 4,096 bytes on Linux but this can be worked around. Linux itself has no hard path length limits.[122][123] /wiki/Installable_File_System
Maximum combined filename/filetype length is 236 bytes; each component has an individual maximum length of 255 bytes.
Maximum pathname length is 4,096 bytes, but quoted limits on individual components add up to 1,664 bytes.
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-disk 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.
The on-disk structures have no inherent limit. Particular Installable File System drivers and operating systems may impose limits of their own, however. Limited by its Current Directory Structure (CDS), DOS does not support more than 32 directory levels (except for DR DOS 3.31-6.0) or full pathnames longer than 66 bytes for FAT, or 255 characters for LFNs. Windows NT does not support full pathnames longer than 32,767 bytes for NTFS. Older POSIX APIs which rely on the PATH_MAX constant have a limit of 4,096 bytes on Linux but this can be worked around. Linux itself has no hard path length limits.[122][123] /wiki/Installable_File_System
QFS allows files to exceed the size of disk when used with its integrated HSM, as only part of the file need reside on disk at any one time.
QFS allows files to exceed the size of disk when used with its integrated HSM, as only part of the file need reside on disk at any one time.
Steven Sinofsky (January 16, 2012). "Building the next generation file system for Windows: ReFS". /wiki/Steven_Sinofsky
Steven Sinofsky (January 16, 2012). "Building the next generation file system for Windows: ReFS". /wiki/Steven_Sinofsky
Amigo (2015-04-02). "Invalid Characters in File Names". Amigo's Technical Notes. Retrieved 2020-10-20. https://amigotechnotes.wordpress.com/2015/04/02/invalid-characters-in-file-names/
Steven Sinofsky (January 16, 2012). "Building the next generation file system for Windows: ReFS". /wiki/Steven_Sinofsky
Steven Sinofsky (January 16, 2012). "Building the next generation file system for Windows: ReFS". /wiki/Steven_Sinofsky
"Resilient File System (ReFS) overview". Microsoft Docs. Retrieved 2017-11-07. https://docs.microsoft.com/en-us/windows-server/storage/refs/refs-overview
Steven Sinofsky (January 16, 2012). "Building the next generation file system for Windows: ReFS". /wiki/Steven_Sinofsky
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-disk 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.
The on-disk structures have no inherent limit. Particular Installable File System drivers and operating systems may impose limits of their own, however. Limited by its Current Directory Structure (CDS), DOS does not support more than 32 directory levels (except for DR DOS 3.31-6.0) or full pathnames longer than 66 bytes for FAT, or 255 characters for LFNs. Windows NT does not support full pathnames longer than 32,767 bytes for NTFS. Older POSIX APIs which rely on the PATH_MAX constant have a limit of 4,096 bytes on Linux but this can be worked around. Linux itself has no hard path length limits.[122][123] /wiki/Installable_File_System
ReiserFS has a theoretical maximum file size of 1 EiB (1.152 EB), but "page cache limits this to 8 Ti on architectures with 32 bit int"[119] /wiki/Exbibyte
The on-disk structures have no inherent limit. Particular Installable File System drivers and operating systems may impose limits of their own, however. Limited by its Current Directory Structure (CDS), DOS does not support more than 32 directory levels (except for DR DOS 3.31-6.0) or full pathnames longer than 66 bytes for FAT, or 255 characters for LFNs. Windows NT does not support full pathnames longer than 32,767 bytes for NTFS. Older POSIX APIs which rely on the PATH_MAX constant have a limit of 4,096 bytes on Linux but this can be worked around. Linux itself has no hard path length limits.[122][123] /wiki/Installable_File_System
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-disk 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.
The on-disk structures have no inherent limit. Particular Installable File System drivers and operating systems may impose limits of their own, however. Limited by its Current Directory Structure (CDS), DOS does not support more than 32 directory levels (except for DR DOS 3.31-6.0) or full pathnames longer than 66 bytes for FAT, or 255 characters for LFNs. Windows NT does not support full pathnames longer than 32,767 bytes for NTFS. Older POSIX APIs which rely on the PATH_MAX constant have a limit of 4,096 bytes on Linux but this can be worked around. Linux itself has no hard path length limits.[122][123] /wiki/Installable_File_System
This restriction might be lifted in newer versions.
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-disk 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.
The on-disk structures have no inherent limit. Particular Installable File System drivers and operating systems may impose limits of their own, however. Limited by its Current Directory Structure (CDS), DOS does not support more than 32 directory levels (except for DR DOS 3.31-6.0) or full pathnames longer than 66 bytes for FAT, or 255 characters for LFNs. Windows NT does not support full pathnames longer than 32,767 bytes for NTFS. Older POSIX APIs which rely on the PATH_MAX constant have a limit of 4,096 bytes on Linux but this can be worked around. Linux itself has no hard path length limits.[122][123] /wiki/Installable_File_System
"Maximum Number of UFS Subdirectories". Oracle. Retrieved 2019-02-12. https://docs.oracle.com/cd/E19120-01/open.solaris/819-2723/fsfilesysappx-5/index.html
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-disk 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.
The on-disk structures have no inherent limit. Particular Installable File System drivers and operating systems may impose limits of their own, however. Limited by its Current Directory Structure (CDS), DOS does not support more than 32 directory levels (except for DR DOS 3.31-6.0) or full pathnames longer than 66 bytes for FAT, or 255 characters for LFNs. Windows NT does not support full pathnames longer than 32,767 bytes for NTFS. Older POSIX APIs which rely on the PATH_MAX constant have a limit of 4,096 bytes on Linux but this can be worked around. Linux itself has no hard path length limits.[122][123] /wiki/Installable_File_System
"Frequently Asked Questions for FreeBSD 9.X and 10.X". FreeBSD Documentation Project. Retrieved 2016-03-20. If there was not a fsck(8) memory limit the maximum filesystem size would be 2 ^ 64 (blocks) * 32 KiB (32.76 KB) => 16 Exa * 32 KiB (32.76 KB) => 512 ZettaBytes. https://www.freebsd.org/doc/faq/book.html
"Maximum Number of UFS Subdirectories". Oracle. Retrieved 2019-02-12. https://docs.oracle.com/cd/E19120-01/open.solaris/819-2723/fsfilesysappx-5/index.html
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-disk 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.
The on-disk structures have no inherent limit. Particular Installable File System drivers and operating systems may impose limits of their own, however. Limited by its Current Directory Structure (CDS), DOS does not support more than 32 directory levels (except for DR DOS 3.31-6.0) or full pathnames longer than 66 bytes for FAT, or 255 characters for LFNs. Windows NT does not support full pathnames longer than 32,767 bytes for NTFS. Older POSIX APIs which rely on the PATH_MAX constant have a limit of 4,096 bytes on Linux but this can be worked around. Linux itself has no hard path length limits.[122][123] /wiki/Installable_File_System
The file size in the inode is 1 8-bit byte followed by 1 16-bit word, for 24 bits. The actual maximum was 8,847,360 bytes, with 7 singly-indirect blocks and 1 doubly-indirect block; PWB/UNIX 1.0's variant had 8 singly-indirect blocks, making the maximum 524,288 bytes or half a MB. /wiki/Megabyte
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-disk 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.
The on-disk structures have no inherent limit. Particular Installable File System drivers and operating systems may impose limits of their own, however. Limited by its Current Directory Structure (CDS), DOS does not support more than 32 directory levels (except for DR DOS 3.31-6.0) or full pathnames longer than 66 bytes for FAT, or 255 characters for LFNs. Windows NT does not support full pathnames longer than 32,767 bytes for NTFS. Older POSIX APIs which rely on the PATH_MAX constant have a limit of 4,096 bytes on Linux but this can be worked around. Linux itself has no hard path length limits.[122][123] /wiki/Installable_File_System
The actual maximum was 1,082,201,088 bytes, with 10 direct blocks, 1 singly-indirect block, 1 doubly-indirect block, and 1 triply-indirect block. The 4.0BSD and 4.1BSD versions, and the System V version, used 1,024-byte blocks rather than 512-byte blocks, making the maximum 4,311,812,608 bytes or approximately 4 GiB (4.294 GB). /wiki/BSD
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-disk 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.
Maximum file size on a VMFS volume depends on the block size for that VMFS volume. The figures here are obtained by using the maximum block size.
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-disk 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.
Maximum file size on a VMFS volume depends on the block size for that VMFS volume. The figures here are obtained by using the maximum block size.
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-disk 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.
The on-disk structures have no inherent limit. Particular Installable File System drivers and operating systems may impose limits of their own, however. Limited by its Current Directory Structure (CDS), DOS does not support more than 32 directory levels (except for DR DOS 3.31-6.0) or full pathnames longer than 66 bytes for FAT, or 255 characters for LFNs. Windows NT does not support full pathnames longer than 32,767 bytes for NTFS. Older POSIX APIs which rely on the PATH_MAX constant have a limit of 4,096 bytes on Linux but this can be worked around. Linux itself has no hard path length limits.[122][123] /wiki/Installable_File_System
Note that the filename can be much longer XFS#Extended attributes /wiki/XFS#Extended_attributes
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-disk 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.
The on-disk structures have no inherent limit. Particular Installable File System drivers and operating systems may impose limits of their own, however. Limited by its Current Directory Structure (CDS), DOS does not support more than 32 directory levels (except for DR DOS 3.31-6.0) or full pathnames longer than 66 bytes for FAT, or 255 characters for LFNs. Windows NT does not support full pathnames longer than 32,767 bytes for NTFS. Older POSIX APIs which rely on the PATH_MAX constant have a limit of 4,096 bytes on Linux but this can be worked around. Linux itself has no hard path length limits.[122][123] /wiki/Installable_File_System
XFS has a limitation under Linux 2.4 of 64 TiB (70.36 TB) file size, but Linux 2.4 only supports a maximum block size of 2 TiB (2.199 TB). This limitation is not present under IRIX. /wiki/Tebibyte
XFS has a limitation under Linux 2.4 of 64 TiB (70.36 TB) file size, but Linux 2.4 only supports a maximum block size of 2 TiB (2.199 TB). This limitation is not present under IRIX. /wiki/Tebibyte
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-disk 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.
The on-disk structures have no inherent limit. Particular Installable File System drivers and operating systems may impose limits of their own, however. Limited by its Current Directory Structure (CDS), DOS does not support more than 32 directory levels (except for DR DOS 3.31-6.0) or full pathnames longer than 66 bytes for FAT, or 255 characters for LFNs. Windows NT does not support full pathnames longer than 32,767 bytes for NTFS. Older POSIX APIs which rely on the PATH_MAX constant have a limit of 4,096 bytes on Linux but this can be worked around. Linux itself has no hard path length limits.[122][123] /wiki/Installable_File_System
The on-disk structures have no inherent limit. Particular Installable File System drivers and operating systems may impose limits of their own, however. Limited by its Current Directory Structure (CDS), DOS does not support more than 32 directory levels (except for DR DOS 3.31-6.0) or full pathnames longer than 66 bytes for FAT, or 255 characters for LFNs. Windows NT does not support full pathnames longer than 32,767 bytes for NTFS. Older POSIX APIs which rely on the PATH_MAX constant have a limit of 4,096 bytes on Linux but this can be worked around. Linux itself has no hard path length limits.[122][123] /wiki/Installable_File_System
These are the restrictions imposed by the on-disk directory entry structures themselves. Particular Installable File System drivers may place restrictions of their own on file and directory names; operating systems may also place restrictions of their own, across all filesystems. DOS, Windows, and OS/2 allow only the following characters from the current 8-bit OEM codepage in SFNs: A-Z, 0-9, characters ! # $ % & ' ( ) - @ ^ _ ` { } ~, as well as 0x80-0xFF and 0x20 (SPACE). Specifically, lowercase letters a-z, characters " * / : < > ? \ | + , . ; = [ ], control codes 0x00-0x1F, 0x7F and in some cases also 0xE5 are not allowed.) In LFNs, any UCS-2 Unicode except \ / : ? * " > < | and NUL are allowed in file and directory names across all filesystems. Unix-like systems disallow the characters / and NUL in file and directory names across all filesystems. /wiki/Installable_File_System
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 128 KiB (131.0 KB) for FAT — which is the cluster size range allowed by the on-disk data structures, although some Installable File System drivers and operating systems do not support cluster sizes larger than 32 KiB (32.76 KB)). /wiki/Kibibyte