File:File system fragmentation.svg is a vector version of this file. It should be used in place of this PNG file. File:File system fragmentation.png → File:File system fragmentation.svg For more information, see Help:SVG. In other languages Alemannisch ∙ Bahasa Indonesia ∙ Bahasa Melayu ∙ British English ∙ català ∙ čeština ∙ dansk ∙ Deutsch ∙ eesti ∙ English ∙ español ∙ Esperanto ∙ euskara ∙ français ∙ Frysk ∙ galego ∙ hrvatski ∙ Ido ∙ italiano ∙ lietuvių ∙ magyar ∙ Nederlands ∙ norsk bokmål ∙ norsk nynorsk ∙ occitan ∙ Plattdüütsch ∙ polski ∙ português ∙ português do Brasil ∙ română ∙ Scots ∙ sicilianu ∙ slovenčina ∙ slovenščina ∙ suomi ∙ svenska ∙ Tiếng Việt ∙ Türkçe ∙ vèneto ∙ Ελληνικά ∙ беларуская (тарашкевіца) ∙ български ∙ македонски ∙ нохчийн ∙ русский ∙ српски / srpski ∙ татарча/tatarça ∙ українська ∙ ქართული ∙ հայերեն ∙ বাংলা ∙ தமிழ் ∙ മലയാളം ∙ ไทย ∙ 한국어 ∙ 日本語 ∙ 简体中文 ∙ 繁體中文 ∙ עברית ∙ العربية ∙ فارسی ∙ +/−

 

Example of how file systems become fragmented. The following is from the article of the same name on Wikipedia:

A blank disk has 5 files, A, B, C, D and E each using 10 blocks of space (for this section, a block is an allocation unit of that system, it could be 1K, 100K or 1 megabyte and is not any specific size). On a blank disk, all of these files will be allocated one after the other. (Example (1) on the image.) If file B is deleted, there are two options, leave the space for B empty and use it again later, or compress all the files after B so that the empty space follows it. This could be time consuming if there were hundreds or thousands of files which needed to be moved, so in general the empty space is simply left there, marked in a table as available for later use, then used again as needed. (Example (2) on the image.) Now, if a new file, F, is allocated 7 blocks of space, it can be placed into the first 7 blocks of the space formerly holding the file B and the 3 blocks following it will remain available. (Example (3) on the image.) If another new file, G is added, and needs only three blocks, it could then occupy the space after F and before C. (Example (4) on the image). Now, if subsequently F needs to be expanded, since the space immediately following it is no longer available, there are two options: (1) add a new block somewhere else and indicate that F has a second extent, or (2) move the file F to someplace else where it can be created as one contiguous file of the new, larger size. The latter operation may not be possible as the file may be larger than any one contiguous space available, or the file conceivably could be so large the operation would take an undesirably long period of time, thus the usual practice is simply to create an extent somewhere else and chain the new extent onto the old one. (Example (5) on the image.) Repeat this practice hundreds or thousands of times and eventually the file system has many free segments in many places and many files may be spread over many extents. If, as a result of free space fragmentation, a newly created file (or a file which has been extended) has to be placed in a large number of extents, access time for that file (or for all files) may become excessively long.

This work has been released into the public domain by its author, Rfc1394. This applies worldwide. In some countries this may not be legally possible; if so: Rfc1394 grants anyone the right to use this work for any purpose, without any conditions, unless such conditions are required by law.