首页 | 文学 | 典籍 | 影视 | 音乐 | 科技 | 人物 | 原创 | 文摘 | 维基文化 | 综合参考

 开放、中立,源自维基百科

Personal tools
Your continued donations keep Wikipedia running!    

File system

Mirror of English Wikipedia, the free encyclopedia

Jump to: navigation, search

In computing, a file system is a method for storing and organizing computer files and the data they contain to make it easy to find and access them. File systems may use a storage device such as a hard disk or CD-ROM and involve maintaining the physical location of the files, or they may be virtual and exist only as an access method for virtual data or for data over a network (e.g. NFS).

More formally, a file system is a set of abstract data types that are implemented for the storage, hierarchical organization, manipulation, navigation, access, and retrieval of data.

Contents

Aspects of file systems

The most familiar file systems make use of an underlying data storage device that offers access to an array of fixed-size blocks, sometimes called sectors, generally 512 bytes each. The file system software is responsible for organizing these sectors into files and directories, and keeping track of which sectors belong to which file and which are not being used.

However, file systems need not make use of a storage device at all. A file system can be used to organize and represent access to any data, whether it be stored or dynamically generated (eg, from a network connection).

Whether the file system has an underlying storage device or not, file systems typically have directories which associate file names with files, usually by connecting the file name to an index into a file allocation table of some sort, such as the FAT in an MS-DOS file system, or an inode in a Unix-like filesystem. Directory structures may be flat, or allow hierarchies where directories may contain subdirectories. In some file systems, file names are structured, with special syntax for filename extensions and version numbers. In others, file names are simple strings, and per-file metadata is stored elsewhere.

The hierarchical filesystem was an early research interest of Dennis Ritchie of Unix fame; previous implementations were restricted to only a few levels, notably the IBM implementations, even of their early databases like IMS. After the success of Unix, Ritchie extended the filesystem concept to every object in his later operating system developments, such as Plan 9 and Inferno.

Traditional filesystems offer facilities to create, move and delete both files and directories. They lack facilities to create additional links to a directory (hard links in Unix), rename parent links (".." in Unix-like OS), and create bidirectional links to files.

Traditional filesystems also offer facilities to truncate, append to, create, move, delete and in-place modify files. They do not offer facilities to prepend to or truncate from the beginning of a file, let alone arbitrary insertion into or deletion from a file. The operations provided are highly asymmetric and lack the generality to be useful in unexpected contexts. For example, interprocess pipes in Unix have to be implemented outside of the filesystem because it does not offer truncation from the beginning of files.

Secure access to basic file system operations can be based on a scheme of access control lists or capabilities. Research has shown access control lists to be difficult to secure properly, which is why research operating systems tend to use capabilities. Commercial file systems still use access control lists. see: secure computing

Types of file systems

File system types can be classified into disk file systems, network file systems and special purpose file systems.

Disk file systems

A disk file system is a file system designed for the storage of files on a data storage device, most commonly a disk drive, which might be directly or indirectly connected to the computer. Examples of disk file systems include FAT, NTFS, HFS, ext2, ISO 9660, ODS-5, and UDF. Some disk file systems are also journaling file systems or versioning file systems.

Database file systems

New concepts for file management are database-based file systems. Instead of hierarchical structured management, files are identified by their characteristics, like type of file, topic, author, or similar metadata. Therefore a file search can be formulated in SQL or in natural speech. Examples include Gnome VFS, BFS, HFSJ, and WinFS.

Transactional file systems

This is a special kind of file system in that it logs events or transactions to files. Each operation that you do may involve changes to a number of different files and disk structures. In many cases, these changes are related, meaning that it is important that they all be executed at the same time. Take for example a bank sending another bank some money electronically. The bank's computer will "send" the transfer instruction to the other bank and also update its own records to indicate the transfer has occurred. If for some reason the computer crashes before it has had a chance to update its own records, then on reset, there will be no record of the transfer but the bank will be missing some money. A transactional system can rebuild the actions by resynchronizing the "transactions" on both ends to correct the failure. All transactions can be saved, as well, providing a complete record of what was done and where. This type of file system is designed and intended to be fault tolerant and necessarily, incurs a high degree of overhead.

Special purpose file systems

A special purpose file system is basically any file system that is not a disk file system or network file system. This includes systems where the files are arranged dynamically by software, intended for such purposes as communication between computer processes or temporary file space.

Special purpose file systems are most commonly used by file-centric operating systems such as Unix. Examples include the procfs (/proc) filesystem used by some Unix variants, which grants access to information about processes and other operating system features.

Deep space science exploration craft, like Voyager I & II used digital tape based special file systems. Most modern space exploration craft like Cassini-Huygens used Real-time operating system file systems or RTOS influenced file systems. The Mars Rovers are one such example of an RTOS file system, important in this case because they are implemented in flash memory.

File systems and operating systems

Most operating systems provide a file system, as a file system is an integral part of any modern operating system. Early microcomputer operating systems' only real task was file management - a fact reflected in their names (see DOS and QDOS). Some early operating systems had a separate component for handling file systems which was called a disk operating system. On some microcomputers, the disk operating system was loaded separately from the rest of the operating system. On early operating systems, there was usually support for only one, native, unnamed file system; for example, CP/M supports only its own file system, which might be called "CP/M file system" if needed, but which didn't bear any official name at all.

Because of this, there needs to be an interface provided by the operating system software between the user and the file system. This interface can be textual (such as provided by a command line interface, such as the Unix shell, or OpenVMS DCL) or graphical (such as provided by a graphical user interface, such as file browsers). If graphical, the metaphor of the folder, containing documents, other files, and nested folders is often used (see also: directory and folder).

Flat file systems

In a flat file system, there are no directories — everything is stored at the same (root) level on the media, be it a hard disk, floppy disk, etc. While simple, this system rapidly becomes inefficient as the number of files grows, and makes it difficult for users to organise data into related groups.

Like many small systems before it, the original Apple Macintosh featured a flat file system, called Macintosh File System. Its version of Mac OS was unusual in that the file management software (Macintosh Finder) created the illusion of a partially hierarchical filing system on top of MFS. MFS was quickly replaced with Hierarchical File System, which supported real directories.

File systems under Unix

Unix and Unix-like operating systems assign a device name to each device, but this is not how the files on that device are accessed. Instead, Unix creates a virtual file system, which makes all the files on all the devices appear to exist under one hierarchy. This means, in Unix, there is one root directory, and every file existing on the system is located under it somewhere. Furthermore, the Unix root directory does not have to be in any physical place. It might not be on your first hard drive - it might not even be on your computer. Unix can use a network shared resource as its root directory.

To gain access to files on another device, you must first inform the operating system where in the directory tree you would like those files to appear. This process is called mounting a file system. For example, to access the files on a CD-ROM, informally, one must tell the operating system "Take the file system from this CD-ROM and make it appear under the directory /mnt". The directory given to the operating system is called the mount point - in this case it is /mnt. The /mnt directory exists on all Unix systems (as specified in the Filesystem Hierarchy Standard) and is intended specifically for use as a mount point for temporary media like floppy disks or CDs. It may be empty, or it may contain subdirectories for mounting individual devices. Generally, only the administrator (i.e. root user) may authorize the mounting of file systems.

Unix-like operating systems often include software and tools that assist in the mounting process and provide it new functionality. Some of these strategies have been coined "auto-mounting" as a reflection of their purpose.

  1. In many situations, filesystems other than the root need to be available as soon as the operating system has booted. All Unix-like systems therefore provide a facility for mounting filesystems at boot time. System administrators define these filesystems in the configuration file fstab, which also indicates options and mount points.
  2. In some situations, there is no need to mount certain filesystems at boot time, although their use may be desired thereafter. There are some utilities for Unix-like systems that allow the mounting of predefined filesystems upon demand.
  3. Removable media have become very common with microcomputer platforms. They allow programs and data to be transferred between machines without a physical connection. Two common examples include CD-ROMs and DVDs. Utilities have therefore been developed to detect the presence and availability of a medium and then mount that medium without any user intervention.
  4. Progressive Unix-like systems have also introduced a concept called supermounting. For example, a floppy disk that has been supermounted can be physically removed from the system. Under normal circumstances, the disk should have been synchronised and then unmounted before its removal. Provided synchronisation has occurred, a different disk can be inserted into the drive. The system automatically notices that the disk has changed and updates the mount point contents to reflect the new medium. Similar functionality is found on standard Windows machines.

File systems under Mac OS X

Mac OS X uses a file system that it inherited from Mac OS called HFS Plus. HFS Plus is a metadata-rich and case preserving but case insensitive file system. Due to the Unix roots of Mac OS X, Unix permissions were added to HFS Plus. Later versions of HFS Plus added a journal to prevent corruption of the file system structure and introduced a number of optimizations to the allocation algorithms in an attempt to defragment files automatically without requiring an external defragmenter.

Filenames can be up to 255 characters. HFS Plus uses Unicode to store filenames. On Mac OS X, the filetype can come from the Type code stored in file's metadata or the filename.

HFS Plus has three kinds of links: Hard links, Symbolic links and Aliases. Aliases are designed to maintain a link to their original file even if they are moved or renamed.

File systems under Plan 9 from Bell Labs

Plan 9 from Bell Labs was originally designed to extend some of Unix's good points, and to introduce some new ideas of its own while fixing the shortcomings of Unix.

With respect to file systems, the Unix system of treating things as files was continued, but in Plan 9, everything is treated as a file, and accessed as a file would be (ie., no ioctl or mmap). Perhaps surprisingly, while the file interface is made universal it is also simplified considerably, for example symlinks, hard links and suid are made obsolete, and an atomic create/open operation is introduced. More importantly the set of file operations becomes well defined and subversions of this like ioctl are eliminated.

Secondly, the underlying 9P protocol was used to remove the difference between local and remote files (modulo a possible difference in latency). This has the advantage that a device or devices, represented by files, on a remote computer, could be used as though it were the local computer's own device(s). This means that under Plan 9, multiple file servers provide access to devices, classing them as file systems. Servers for "synthetic" file systems can also run in user space bringing many of the advantages of micro kernel systems while maintaining the simplicity of the system.

Everything on a Plan 9 system has an abstraction as a file; networking, graphics, debugging, authentication, capabilities, encryption and other services are accessed via I-O operations on file descriptors. This allows for example to use the IP stack of a gateway machine without need of NAT, or provides a network transparent window system without the need of any extra code.

For example, a Plan-9 application receives FTP service by opening an FTP site. The ftpfs server handles the open by essentially mounting the remote FTP site as part of the local file system. With ftpfs as an intermediary, the application can now use the usual file-system operations to access the FTP site as if it were part of the local file system. Another example is the mail system which uses file servers that synthesize virtual files and directories to represent a user mailbox as /mail/fs/mbox. The wikifs provides a file system interface to a wiki.

These file systems are organized with the help of private, per-process namespaces, allowing each process to have a different view of the many file systems that provide resources in a distributed system.

The Inferno operating system shares these concepts with Plan 9.

File systems under Microsoft Windows

Microsoft Windows developed out of an earlier operating system (MS-DOS which in turn was based on QDOS and that on CP/M-80, which took many ideas from still earlier operating systems, notably several from DEC), and has added both file system and user interface ideas from several other sources since its first release (Unix, OS/2, etc). As such, Windows makes use of the FAT (File Allocation Table) and NTFS (New Technology File System) filesystems. Older versions of the FAT file system had file name length limits, plus had restrictions on the maximum size of FAT-formatted disks or partitions.

NTFS, introduced with the Windows NT operating system, allowed ACL-based permission control. Hard links, multiple file streams, attribute indexing, quota tracking, compression and mount-points for other file systems (called "junctions") are also supported, though not all well-documented.

Unlike many other operating systems, Windows uses a drive letter abstraction at the user level to distinguish one disk or partition from another. For example, the path C:\WINDOWS\ represents a directory WINDOWS on the partition represented by the letter C. The C drive is most commonly used for the primary hard disk partition, on which Windows is installed and from which it boots. This "tradition" has become so firmly ingrained that bugs came about in older versions of Windows which made assumptions that the drive that the operating system was installed on was C. The tradition of using "C" for the drive letter can be traced to MS-DOS, where the letters A and B were reserved for up to two floppy disk drives; in a common configuration, A would be the 3½-inch floppy drive, and B the 5¼-inch one. Network drives may also be mapped to drive letters.

Since Windows interacts with the user via a graphical user interface, its documentation refers to directories as a folder which contains files, and is represented graphically with a folder icon.

File systems under OpenVMS

This topic is discussed here: Files-11

File systems under MVS [IBM Mainframe]

This topic is discussed here: MVS#MVS filesystem

Comparison

General information

File system Creator Introduced in Original operating system
DECtape DEC 1964 PDP-6 Monitor
Level-D DEC 1968 TOPS-10
V6FS Bell Labs 1972 Version 6 Unix
RT-11 DEC 1973 RT-11
FAT12 Microsoft 1977 Microsoft Disk BASIC
V7FS Bell Labs 1979 Version 7 Unix
ODS-2 DEC 1979 OpenVMS
FFS Kirk McKusick 1983 4.2BSD
MFS Apple Computer 1984 Mac OS
HFS Apple Computer 1985 Mac OS
OFS54 Metacomco for Commodore 1985 Amiga OS
NWFS Novell 1985 NetWare 286
Amiga FFS Commodore 1987 Amiga OS 1.3
FAT16 Microsoft 1987 MS-DOS 3.31
HPFS IBM & Microsoft 1988 OS/2
JFS IBM 1990 AIX11
VxFS VERITAS 1991 SVR4.0
AdvFS DEC Before 1993 Digital Unix
NTFS Microsoft, Gary Kimura, Tom Miller 1993 Windows NT
LFS Margo Seltzer 1993 Berkeley Sprite
ext2 Rémy Card 1993 Linux
UFS1 Kirk McKusick 1994 4.4BSD
XFS SGI 1994 IRIX
UDF ISO/ECMA/OSTA 1995 -
FAT32 Microsoft 1996 Windows 95b10
QFS Sun Microsystems 1996 Solaris
Be File System Be Inc., D. Giampaolo, C. Meurillon 1996 BeOS
HFS Plus Apple 1998 Mac OS 8.1
NSS Novell 1998 NetWare 5
ext3 Stephen Tweedie 1999 Linux
JFS2 IBM 1999 OS/2 WSeB
GFS Sistina(Red Hat) 2000 Linux
GFS2 Red Hat 2006 Linux
ReiserFS Namesys 2001 Linux
FATX Microsoft 2002 Xbox
UFS2 Kirk McKusick 2002 FreeBSD 5.0
ODS-5 DEC 2003 OpenVMS 8.0
Fossil Bell Labs 2003 Plan 9 from Bell Labs 4
Google File System Google 2003 Linux
ZFS Sun Microsystems 2004 Solaris
Reiser4 Namesys 2004 Linux
NILFS NTT 2005 Linux
File system Creator Introduced in Original operating system

Limits

Maximum filename length Allowable characters in directory entries25 Maximum pathname length Maximum file size Maximum volume size 4
DECtape 6.3 A-Z, 0-9 DTxN:FILNAM.EXT = 15 369,280 bytes (577 * 640) 369,920 Bytes (578 * 640)
Level-D 6.3 A-Z, 0-9 DEVICE:FILNAM.EXT[PROJCT,PROGRM] = 7 + 10 + 15 = 32; + 5*7 for SFDs = 67 34,359,738,368 words (2**35-1); 206,158,430,208 SIXBIT bytes Approx 12 GB (64 * 178MB)
RT-11 12 bytes A-Z, 0-9, $ 16 bytes 33,554,432 bytes (65536 * 512) 33,554,432 Bytes
V6FS 14 bytes 24 Any byte except NUL and / 26 No limit defined 12 8MiB 57 2TiB
V7FS 14 bytes 24 Any byte except NUL and / 26 No limit defined 12 1GiB 58 2TiB
FAT12 255 bytes 24 Any Unicode except NUL 24 26 No limit defined 12 32MiB 1MiB to 32MiB
FAT16 255 bytes 24 Any Unicode except NUL 24 26 No limit defined 12 2GiB 16MiB to 2GiB
FATX 42 bytes 24 ASCII. Unicode not permitted. No limit defined 12 2GiB 16MiB to 2GiB
MFS 255 bytes Any byte except : No path (flat filesystem) 256MiB 256MiB
HFS 31 bytes Any byte except : Unlimited 2GiB 2TiB
FAT32 255 bytes 24 Any Unicode except NUL 24 26 No limit defined 12 4GiB 512MiB to 2TiB 7
HPFS 255 bytes Any byte except NUL 27 No limit defined 12 4GiB 2TiB13
NTFS 255 characters Any Unicode except NUL 32,767 Unicode characters with each path component (directory or filename) up to 255 characters long 12 16EiB 55 16EiB 55
HFS Plus 255 UTF-16 characters 1 Any valid Unicode 2 26 Unlimited 8EiB 8EiB 71
FFS 255 bytes Any byte except NUL 26 No limit defined 12 4GiB 256TiB
UFS1 255 bytes Any byte except NUL 26 No limit defined 12 4GiB to 256TiB 256TiB
UFS2 255 bytes Any byte except NUL 26 No limit defined 12 512GiB to 32PiB 1YiB
ext2 255 bytes Any byte except NUL 26 No limit defined 12 16GiB to 2TiB4 2TiB to 32TiB
ext3 255 bytes Any byte except NUL 26 No limit defined 12 16GiB to 2TiB4 2TiB to 32TiB
GFS 255 Any byte except NUL 26 No limit defined 12 2TB to 8EB63 2TB to 8EB63
ReiserFS 4032 bytes/255 characters Any byte except NUL 26 No limit defined 12 8TiB8 16TiB
Reiser4  ?  ? No limit defined 12 8TiB on x86  ?
XFS 255 bytes Any byte except NUL 26 No limit defined 12 8EiB9 8EiB9
JFS 255 bytes Any byte except NUL 26 No limit defined 12 8EiB 512TiB to 4PiB
JFS2 255 bytes Any Unicode except NUL No limit defined 12 4PiB 32PiB
QFS 255 bytes Any byte except NUL 26 No limit defined 12 16EiB 72 4PiB 72
Be File System 255 bytes Any byte except NUL 26 No limit defined 12 12288 bytes to 260GiB3 256PiB to 2EiB
AdvFS 255 characters Any byte except NUL 26 No limit defined 12 16TiB 16TiB
NSS 256 characters Depends on namespace used 28 Only limited by client 8TiB 8TiB
NWFS 80 bytes 52 Depends on namespace used 28 No limit defined 12 4GiB 1TiB
ODS-5 236 bytes15  ? 4096 bytes16 1TiB 1TiB
VxFS 255 bytes Any byte except NUL 26 No limit defined 12 16EiB  ?
UDF 255 bytes Any Unicode except NUL 1023 bytes 43 16EiB  ?
ZFS 255 bytes Any Unicode except NUL No limit defined 12 16EiB 16EiB
Maximum filename length Allowable characters in directory entries25 Maximum pathname length Maximum file size Maximum volume size 4

Metadata

Stores file owner POSIX file permissions Creation timestamps Last access/read timestamps Last metadata change timestamps Last archive timestamps Access control lists Security/MAC labels Extended attributes/Alternate data streams/forks Checksum/ECC
DECtape No No Yes No No No No No No No
Level-D Yes Yes Yes Yes Yes Yes Yes No No No
RT-11 No No No Yes Yes No No No No No
V6FS Yes Yes No Yes Yes No No No No No
V7FS Yes Yes No Yes Yes No No No No No
FAT12 No No Yes Yes No No No No No 22 No
FAT16 No No Yes Yes No No No No No 22 No
FAT32 No No Yes Yes No No No No No No
HPFS Yes14 No Yes Yes No No No  ? Yes No
NTFS Yes No5 Yes Yes Yes No Yes  ? Yes No
HFS No No Yes No No Yes No No Yes No
HFS Plus Yes Yes Yes Yes Yes Yes Yes  ? Yes No
FFS Yes Yes No Yes Yes No No No No No
UFS1 Yes Yes No Yes Yes No Yes 33 Yes 33 No 32 No
UFS2 Yes Yes Yes Yes Yes No Yes 33 Yes 33 Yes No
LFS Yes Yes No Yes Yes No No No No No
ext2 Yes Yes No Yes Yes No Yes 23 Yes 23 Yes No
ext3 Yes Yes No Yes Yes No Yes 23 Yes 23 Yes No
GFS Yes Yes No Yes Yes No Yes 23 Yes 23 Yes No
ReiserFS Yes Yes No Yes Yes No Yes 23 Yes 23 Yes No
Reiser4 Yes Yes No Yes Yes No No No No No
XFS Yes Yes No Yes Yes No Yes Yes 23 Yes No
JFS Yes Yes Yes Yes Yes No Yes Yes Yes No
QFS Yes Yes Yes Yes Yes Yes Yes No Yes No
Be File System Yes Yes Yes No No No No No Yes No
AdvFS Yes Yes No Yes Yes No Yes No Yes No
NSS Yes Yes Yes31 Yes31 Yes Yes31 Yes  ? Yes19 29 No
NWFS Yes  ? Yes31 Yes31 Yes Yes31 Yes  ? Yes19 29 No
ODS-5 Yes Yes Yes  ?  ? Yes Yes  ? Yes 17 No
VxFS Yes Yes Yes Yes Yes No Yes  ? Yes 23 No
UDF Yes Yes Yes Yes Yes Yes Yes No Yes No
Fossil Yes Yes 61 No Yes Yes No No No No No
ZFS Yes Yes Yes Yes Yes Yes Yes No 69 Yes 60 Yes
Stores file owner POSIX file permissions Creation timestamps Last access/read timestamps Last metadata change timestamps Last archive timestamps Access control lists Security/MAC labels Extended attributes/Alternate data streams/forks Checksum/ECC

Features

Hard links Soft links Block journaling or Metadata-only journaling Case-sensitive Case-preserving File Change Log Incremental snapshots XIP
DECtape No No No No No No No No No
Level-D No No No No No No No No No
RT-11 No No No No No No No No No
V6FS Yes No No No Yes Yes No No No
V7FS Yes No 59 No No Yes Yes No No No
FAT12 No No No No No No No No No
FAT16 No No No No No Partial No No No
FAT32 No No No No No Partial No No No
HPFS No No No No No Yes No  ? No
NTFS Yes Partial34 No Yes Yes36 Yes Yes Yes  ?
HFS Plus Partial Yes No Yes48 Partial35 Yes Yes64 No No
FFS Yes Yes No No Yes Yes No No No
UFS1 Yes Yes No No Yes Yes No No No
UFS2 Yes Yes No No66 Yes Yes No Yes  ?
LFS Yes Yes Yes38 No Yes Yes No Yes No
ext2 Yes Yes No No Yes Yes No No Yes65
ext3 Yes Yes Yes 62 Yes Yes Yes No No  ?
ReiserFS Yes Yes Yes 44 Yes Yes Yes No No  ?
Reiser4 Yes Yes Yes No Yes Yes No  ?  ?
XFS Yes Yes No Yes Yes 40 Yes Yes Yes  ?
JFS Yes Yes No Yes Yes30 Yes No  ?  ?
QFS Yes Yes No No Yes Yes No No No
Be File System Yes Yes No Yes Yes Yes  ?  ? No
NSS Yes Yes  ? Yes Yes20 Yes20 Yes6 Yes No
NWFS Yes53 Yes53 No No Yes20 Yes20 Yes6  ? No
ODS-2 Yes Yes18 No Yes No No Yes Yes No
ODS-5 Yes Yes18 No Yes No Yes Yes Yes  ?
UDF Yes Yes Yes38 Yes38 Yes Yes No No Yes
VxFS Yes Yes Yes No Yes Yes Yes Yes70  ?
Fossil No No No No Yes Yes Yes Yes No
ZFS Yes Yes Yes56 No56 Yes Yes No Yes No
Hard links Soft links Block journaling or Metadata-only journaling Case-sensitive Case-preserving File Change Log Incremental snapshots XIP

Allocation and layout policies

Tail packing Transparent compression Block suballocation Allocate-on-flush Extents Variable file block size 41
DECtape No No No No No No
Level-D No No Yes No Yes No
V6FS No No No No No No
V7FS No No No No No No
FAT12 No No 51 No No No No
FAT16 No No 51 No No No No
FAT32 No No 51 No No No No
HPFS No No No No Yes No
NTFS No Yes Partial No Yes No
HFS Plus No No  ? No Yes No
FFS No No 8:1 45 No No No
UFS1 No No 8:1 45 No No No
UFS2 No No 8:1 45 No No Yes
LFS No No 8:1 45 No No No
ext2 No No 49 No 47 No No No
ext3 No No No 47 No No No
ReiserFS Yes No No No No No
Reiser4 Yes No 50 No Yes Yes 39 No
XFS No No No Yes Yes No
JFS No No Yes No Yes No
QFS No No Yes No No No
Be File System No No No No Yes No
NSS No Yes No No Yes No
NWFS No Yes Yes 42 No No No
ODS-5 No No No No Yes No
VxFS No No  ? No Yes No
UDF No No No  ? 46 Yes No
Fossil No Yes No No No No
ZFS No 68 Yes  ? Yes 67 No Yes
Tail packing Transparent compression Block suballocation Allocate-on-flush Extents Variable block size 41

Notes

Note 1: The Mac OS provides two sets of functions to retrieve file names from a 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.
Note 2: 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.
Note 3: Varies wildly according to block size and fragmentation of block allocation groups.
Note 4: For filesystems that have variable allocation unit (block/cluster) sizes, a range of size are given, indicating the maximum volume sizes for the minimum and the maximum possible allocation unit sizes of the filesystem (e.g. 512 bytes and 128KiB for FAT — which is the cluster size range allowed by the on-disk data structures, although some Installable File System drivers and operating systems do not support cluster sizes larger than 32KiB).
Note 5: NTFS access control lists can express essentially any access policy possible using simple POSIX file permissions, but use of a POSIX-like interface is not supported without an add-on such as Services for UNIX or Cygwin.
Note 6: The file change logs, last entry change timestamps, and other filesystem metadata, are all part of the extensive suite of auditing capabilities built into NDS/eDirectory called NSure Audit. (Filesystem Events tracked by NSure)
Note 7: While FAT32 partitions this large work fine once created, some software won't allow creation of FAT32 partitions larger than 32GiB. This includes, notoriously, the Windows XP installation program. Use FDISK from a Windows ME Emergency Boot Disk to avoid.
Note 8: ReiserFS has a theoretical maximum file size of 1EiB, but "page cache l