Content deleted Content added
GreenC bot (talk | contribs) Rescued 1 archive link; reformat 1 link. Wayback Medic 2.5 |
Guy Harris (talk | contribs) →File scattering: There's no "file sequence" page any more. |
||
(11 intermediate revisions by 11 users not shown) | |||
Line 2:
[[File:FragmentationDefragmentation.gif|thumb|Visualization of fragmentation and then of defragmentation]]In [[computing]], '''file system fragmentation''', sometimes called '''file system aging''', is the tendency of a [[file system]] to lay out the contents of [[Computer file|files]] non-continuously to allow in-place modification of their contents. It is a special case of [[fragmentation (computer)#Data fragmentation|data fragmentation]]. File system fragmentation negatively impacts [[seek time]] in spinning storage media, which is known to hinder [[throughput (disk drive)|throughput]]. Fragmentation can be remedied by re-organizing files and free space back into contiguous areas, a process called [[defragmentation]].
[[Solid-state drive
==Causes==
Line 29:
{{Essay-like|section|date=June 2019}}
Some early file systems were unable to fragment files. One such example was the
DFS used a very simple disk structure and [[Computer file|files]] on [[Hard disk|disk]] were located only by their length and starting sector. This meant that all files had to exist as a continuous block of sectors and fragmentation was not possible. Using the example in the table above, the attempt to expand file F in step five would have failed on such a system with the ''can't extend'' error message. Regardless of how much free space might remain on the disk in total, it was not available to extend the data file.
Line 37:
==Types==
File system fragmentation may occur on several levels:
* Fragmentation within individual [[computer file|file]]s
* Free space fragmentation
Line 50 ⟶ 49:
===File scattering===
File segmentation, also called related-file fragmentation, or application-level (file) fragmentation, refers to the lack of [[locality of reference]] (within the storing medium) between related files
▲File segmentation, also called related-file fragmentation, or application-level (file) fragmentation, refers to the lack of [[locality of reference]] (within the storing medium) between related files (see [[file sequence]] for more detail). Unlike the previous two types of fragmentation, file scattering is a much more vague concept, as it heavily depends on the access pattern of specific applications. This also makes objectively measuring or estimating it very difficult. However, arguably, it is the most critical type of fragmentation, as studies have found that the most frequently accessed files tend to be small compared to available disk throughput per second.<ref name="filesys-contents">{{cite journal | title=A Large-Scale Study of File-System Contents | date=June 1999 | last=Douceur | first=John R. | last2=Bolosky | first2=William J. | journal=ACM SIGMETRICS Performance Evaluation Review | volume=27 | issue=1 | pages=59–70 | doi=10.1145/301464.301480}}</ref>
To avoid related file fragmentation and improve locality of reference (in this case called ''file contiguity''), assumptions or active observations about the operation of applications have to be made. A very frequent assumption made is that it is worthwhile to keep smaller files within a single [[file directory|directory]] together, and lay them out in the natural file system order. While it is often a reasonable assumption, it does not always hold. For example, an application might read several different files, perhaps in different directories, in exactly the same order they were written. Thus, a file system that simply orders all writes successively, might work faster for the given application.
===Data structure fragmentation===
The catalogs or
For some file systems (such as [[NTFS]]{{efn|NTFS reserves 12.5% of the volume for the 'MFT zone', but ''only'' until that space is needed by other files. ''(i.e., if the volume ~ever~ becomes more than 87.5% full, an un-fragmented MFT can no longer be guaranteed.)''<ref name="ntfs-reserves-space-for-mft" />}} and [[Hierarchical File System (Apple)|HFS]]/[[HFS Plus]]<ref name="diskwarrior-hfs-hfsplus">{{cite web |title=DiskWarrior in Depth |url=https://www.alsoft.com/in-depth |website=Alsoft |access-date=22 October 2022}}</ref>), the [[
==Negative consequences==
Line 70 ⟶ 67:
===Preventing fragmentation===
Preemptive techniques attempt to keep fragmentation
Many of today's file systems attempt to
If the final size of a file subject to modification is known, storage for the entire file may be preallocated. For example, the [[Microsoft Windows]] [[swap file]] (page file) can be resized dynamically under normal operation, and therefore can become highly fragmented. This can be prevented by specifying a page file with the same minimum and maximum sizes, effectively preallocating the entire file.
Line 84 ⟶ 81:
{{Main|Defragmentation}}
Retroactive techniques attempt to reduce fragmentation, or the negative effects of fragmentation, after it has occurred. Many file systems provide [[defragmentation]] tools, which attempt to reorder fragments of files, and sometimes also decrease their scattering (i.e. improve their contiguity, or [[locality of reference]]) by keeping either smaller files in [[file directory|directories]], or directory trees, or even
The [[HFS Plus]] file system transparently defragments files that are less than 20 [[MiB]] in size and are broken into 8 or more fragments, when the file is being opened.<ref name=osx-intern>{{cite book |first=Amit |last=Singh |year=2007 |title=Mac OS X Internals: A Systems Approach |publisher=[[Addison Wesley]] |chapter=12 The HFS Plus File System |isbn=0321278542<!--Surprisingly, ISBN lookup on Google Books returns nothing. Hence, I supplied a URL.--> |chapter-url=https://books.google.com/books?id=UZ7AmAEACAAJ}}</ref>
|