Jump to content

Extent (file systems): Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
OS/360
i like commas
 
(19 intermediate revisions by 14 users not shown)
Line 1: Line 1:
{{Short description|Storage area in computer file system}}
{{Refimprove|date=December 2016}}
{{Refimprove|date=December 2016}}


An '''extent''' is a contiguous area of storage reserved for a file in a [[file system]], represented as a range of block numbers, or [[Track (disk drive)|tracks]] on [[Count key data]] devices. A file can consist of zero or more extents; one [[File system fragmentation|file fragment]] requires one extent. The direct benefit is in storing each range compactly as two numbers, instead of canonically storing every block number in the range.<ref name="forensic">{{cite web|url=http://digital-forensics.sans.org/blog/2010/12/20/digital-forensics-understanding-ext4-part-1-extents|title=Understanding Ext4 (part1): Extents|date=2010-12-20|accessdate=2015-02-02|quote=What's really a departure for EXT4 however, is the use of extents rather than the old, inefficient indirect block mechanism used by earlier Unix file systems (e.g. EXT2 and EXT3) for tracking file content. Extents are similar to cluster runs in the NTFS file system; essentially, they specify an initial block address and the number of blocks that make up the extent. A file that is fragmented will have multiple extents, but EXT4 tries very hard to keep files contiguous.}}</ref> Also, extent allocation results in less file fragmentation.
In [[computing]], an '''extent''' is a contiguous area of storage reserved for a file in a [[file system]], represented as a range of block numbers, or [[Track (disk drive)|tracks]] on [[count key data]] devices. A file can consist of zero or more extents; one [[File system fragmentation|file fragment]] requires one extent. The direct benefit is in storing each range compactly as two numbers, instead of [[Canonical form|canonically]] storing every block number in the range.<ref name="forensic">{{cite web|url=http://digital-forensics.sans.org/blog/2010/12/20/digital-forensics-understanding-ext4-part-1-extents|title=Understanding Ext4 (part1): Extents|date=2010-12-20|access-date=2015-02-02|quote=What's really a departure for EXT4 however, is the use of extents rather than the old, inefficient indirect block mechanism used by earlier Unix file systems (e.g. EXT2 and EXT3) for tracking file content. Extents are similar to cluster runs in the NTFS file system; essentially, they specify an initial block address and the number of blocks that make up the extent. A file that is fragmented will have multiple extents, but EXT4 tries very hard to keep files contiguous.|archive-date=2015-02-03|archive-url=https://web.archive.org/web/20150203015625/http://digital-forensics.sans.org/blog/2010/12/20/digital-forensics-understanding-ext4-part-1-extents|url-status=dead}}</ref> Also, extent allocation results in less [[file fragmentation]].


Extent-based file systems can also eliminate most of the [[metadata]] overhead of large files that would traditionally be taken up by the block-allocation tree. But because the savings are small compared to the amount of stored data (for all file sizes in general) but make up a large portion of the metadata (for large files), the overall benefits in storage efficiency and performance are slight.<ref name="ext4doc">{{cite web |url=https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Extent_Tree |title=Ext4 Disk Layout |date=2015-01-26 |accessdate=2015-02-02 |quote=If flex_bg is enabled, it is possible to allocate very large files with a single extent, at a considerable reduction in metadata block use, and some improvement in disk efficiency.}}</ref>
Extent-based file systems can also eliminate most of the [[metadata]] overhead of large files that would traditionally be taken up by the block-allocation tree. But because the savings are small compared to the amount of stored data (for all file sizes in general) but make up a large portion of the metadata (for large files), the overall benefits in storage efficiency and performance are slight.<ref name="ext4doc">{{cite web |url=https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Extent_Tree |title=Ext4 Disk Layout |date=2015-01-26 |access-date=2015-02-02 |quote=If flex_bg is enabled, it is possible to allocate very large files with a single extent, at a considerable reduction in metadata block use, and some improvement in disk efficiency.}}</ref>


In order to resist fragmentation, several extent-based file systems do [[allocate-on-flush]]. Many modern [[fault-tolerant]] file systems also do [[copy-on-write]], although that increases fragmentation. As a similar design, the [[CP/M file system]] uses extents as well, but those do not correspond to the definition given above. [[CP/M]]'s extents appear contiguously as a single block in the combined directory/allocation table, and they do not necessarily correspond to a contiguous data area on disk.
In order to resist fragmentation, several extent-based file systems do [[allocate-on-flush]]. Many modern [[fault-tolerant]] file systems also do [[copy-on-write]], although that increases fragmentation. As a similar design, the [[CP/M file system]] uses extents as well, but those do not correspond to the definition given above. [[CP/M]]'s extents appear contiguously as a single block in the combined directory/allocation table, and they do not necessarily correspond to a contiguous data area on disk.


IBM [System/360 and successors]] allocates files in multiples of disk tracks or [[Cylinder-head-sector#Cylinders|cylinders]]. Files could originally have up to 16 extents, but this restriction has since been lifted. The initial allocation size and the size of additional extents to be allocated if required are specified by the user via [[Job Control Language]]. The system attempts to allocate the initial size as a contiguous area, although this may be split if contiguous space is not available.
IBM [[OS/360 and successors]] allocate files in multiples of disk tracks or [[Cylinder-head-sector#Cylinders|cylinders]]. Files could originally have up to 16 extents, but this restriction has since been lifted. The initial allocation size, and the size of additional extents to be allocated if required, are specified by the user via [[Job Control Language]]. The system attempts to allocate the initial size as a contiguous area, although this may be split if contiguous space is not available.


== Adoption ==
== Adoption ==
Line 17: Line 18:
* [[Be File System|BFS]]{{snd}} [[BeOS]], [[Magnussoft ZETA|Zeta]] and [[Haiku (operating system)|Haiku]] operating systems
* [[Be File System|BFS]]{{snd}} [[BeOS]], [[Magnussoft ZETA|Zeta]] and [[Haiku (operating system)|Haiku]] operating systems
* [[Btrfs]]{{snd}} Extent-based [[copy-on-write]] (COW) file system for Linux
* [[Btrfs]]{{snd}} Extent-based [[copy-on-write]] (COW) file system for Linux
* EFS{{snd}} Extent File System{{snd}} [[Silicon Graphics|SGI's]] first-generation file system for [[Irix]].
* EFS{{snd}} Extent File System{{snd}} [[Silicon Graphics|SGI's]] first-generation file system for [[Irix]]
* [[Ext4]]{{snd}} [[Linux kernel|Linux]] filesystem (when the configuration enables extents{{snd}} the default in Linux since version 2.6.23)
* [[Ext4]]{{snd}} [[Linux kernel|Linux]] filesystem (when the configuration enables extents{{snd}} the default in Linux since version 2.6.23)
* [[Files-11]]{{snd}} [[Digital Equipment Corporation]] (subsequently [[Hewlett-Packard]]) [[OpenVMS]] filesystem.
* [[Files-11]]{{snd}} [[OpenVMS]] filesystem
* [[Hierarchical File System|HFS]] and [[HFS Plus]]{{snd}} Hierarchical File System{{snd}} [[Apple Inc.|Apple]] [[Macintosh]] filesystems
* [[Hierarchical File System (Apple)|HFS]] and [[HFS Plus]]{{snd}} Hierarchical File System{{snd}} [[Apple Inc.|Apple]] [[Macintosh]] filesystems
* [[High Performance File System]] (HPFS) {{snd}} on [[OS/2]] and [[eComStation]]
* [[High Performance File System]] (HPFS) {{snd}} on [[OS/2]], [[eComStation]] and [[ArcaOS]]
* IceFS{{snd}} IceFileSystem{{snd}} optional file system for [[MorphOS]]
* IceFS{{snd}} IceFileSystem{{snd}} optional file system for [[MorphOS]]
* [[IBM Journaled File System 2 (JFS2)|JFS]]{{snd}} Journaled File System{{snd}} used by [[AIX (operating system)|AIX]], [[OS/2]]/eComStation and [[Linux]] operating systems
* [[IBM Journaled File System 2 (JFS2)|JFS]]{{snd}} Journaled File System{{snd}} used by [[AIX (operating system)|AIX]], [[OS/2]]/eComStation/ArcaOS and [[Linux]] operating systems
* [[ISO 9660]]{{snd}} Extent-based file system for optical disc media
* [[ISO 9660]]{{snd}} Extent-based file system for optical disc media
* [[Microsoft SQL Server]]{{snd}} versions 2000–2008 support extents of up to 64&nbsp;KB<ref>{{cite web|url=http://msdn.microsoft.com/en-us/library/ms190969.aspx |title=Understanding Pages and Extents |website=msdn.microsoft.com |date= |accessdate=2014-08-14}}</ref>
* [[Microsoft SQL Server]]{{snd}} versions 2000–2008 support extents of up to 64&nbsp;KB<ref>{{cite web|url=http://msdn.microsoft.com/en-us/library/ms190969.aspx |title=Understanding Pages and Extents |website=[[Microsoft Developer Network]] |access-date=2014-08-14}}</ref>
* [[Multi-Programming Executive]]{{snd}} a filesystem by [[Hewlett-Packard]]
* [[Multi-Programming Executive]]{{snd}} a filesystem by [[Hewlett-Packard]]
* [[NTFS]] called runs
* [[NTFS]]
* [[OCFS2]]{{snd}} Oracle Cluster File System{{snd}} a [[shared-disk file system]] for Linux
* [[OCFS2]]{{snd}} Oracle Cluster File System{{snd}} a [[shared-disk file system]] for Linux
* [[Reiser4]]{{snd}} Linux filesystem (in "extents" mode)
* [[Reiser4]]{{snd}} Linux filesystem (in "extents" mode)

Latest revision as of 00:21, 25 March 2024

In computing, an extent is a contiguous area of storage reserved for a file in a file system, represented as a range of block numbers, or tracks on count key data devices. A file can consist of zero or more extents; one file fragment requires one extent. The direct benefit is in storing each range compactly as two numbers, instead of canonically storing every block number in the range.[1] Also, extent allocation results in less file fragmentation.

Extent-based file systems can also eliminate most of the metadata overhead of large files that would traditionally be taken up by the block-allocation tree. But because the savings are small compared to the amount of stored data (for all file sizes in general) but make up a large portion of the metadata (for large files), the overall benefits in storage efficiency and performance are slight.[2]

In order to resist fragmentation, several extent-based file systems do allocate-on-flush. Many modern fault-tolerant file systems also do copy-on-write, although that increases fragmentation. As a similar design, the CP/M file system uses extents as well, but those do not correspond to the definition given above. CP/M's extents appear contiguously as a single block in the combined directory/allocation table, and they do not necessarily correspond to a contiguous data area on disk.

IBM OS/360 and successors allocate files in multiples of disk tracks or cylinders. Files could originally have up to 16 extents, but this restriction has since been lifted. The initial allocation size, and the size of additional extents to be allocated if required, are specified by the user via Job Control Language. The system attempts to allocate the initial size as a contiguous area, although this may be split if contiguous space is not available.

Adoption

[edit]

The systems supporting filesystem extents include the following:

See also

[edit]

References

[edit]
  1. ^ "Understanding Ext4 (part1): Extents". 2010-12-20. Archived from the original on 2015-02-03. Retrieved 2015-02-02. What's really a departure for EXT4 however, is the use of extents rather than the old, inefficient indirect block mechanism used by earlier Unix file systems (e.g. EXT2 and EXT3) for tracking file content. Extents are similar to cluster runs in the NTFS file system; essentially, they specify an initial block address and the number of blocks that make up the extent. A file that is fragmented will have multiple extents, but EXT4 tries very hard to keep files contiguous.
  2. ^ "Ext4 Disk Layout". 2015-01-26. Retrieved 2015-02-02. If flex_bg is enabled, it is possible to allocate very large files with a single extent, at a considerable reduction in metadata block use, and some improvement in disk efficiency.
  3. ^ "Understanding Pages and Extents". Microsoft Developer Network. Retrieved 2014-08-14.
[edit]