Файл разбивается на отдельные части (фрагменты) в том случае, если драйвер файловой системы не может отыскать свободный участок дискового пространства, в который полностью умещался бы сохраняемый файл. В этом случае, файл разбивается на фрагменты различной длины. В зависимости от найденных свободных "дыр", куски файла записываются в разные части общего пространства диска. О том, где хранится каждая часть файла, записано в таблице размещения файлов.¹ При чтении такого файла, жесткий диск многократно позиционирует (передвигает) рычаг с головками.² Если файл не разбит на фрагменты, то рычаг с головками перемещается два раза, сначала в таблицу размещения файлов (получение координат о расположении файла в файловой области), затем для чтения файла целиком. Указанные выше "дыры" появляются на местах удаленных файлов. Очевидно, что при сильной фрагментации файлов, рычаг с головками находится над поверхностью металлических пластин в непрерывном действии. Нагрузка на движущиеся части ведет к общему нагреву жесткого диска, что сокращает срок его службы. Разумеется, используется кэширование, но при огромном количестве файлов его недостаточно.
     Чтобы не допускать фрагментации, необходимо написать довольно сложный драйвер файловой системы, который перед сохранением каждого файла будет производить частичную дефрагментацию файловой системы, чтобы новый файл записать уже непрерывно (без фрагментов). В ходе работы, такой драйвер существенно замедлит работу ОС, поскольку при перемещении, допустим, файла объемом 1 и более гигабайт, потребуется немалое время. Такие файловые операции приведут к многочисленным задержкам в работе системы и снова к нагреву жесткого диска. Интересно, что с появлением новых жестких дисков формата SSD (Solid State Disk), где информация хранится в специальных микрочипах энергонезависимой памяти, операция дефрагментации не требуется, поскольку в устройстве нет движущихся частей, так что разработка драйвера, предотвращающего фрагментацию файловой системы уже никогда не будет востребована.
     С некоторым предостережением хочется отозваться о сегодняшних SSD-дисках. Технология предполагает ограниченное число циклов записи в ячейки памяти. В сети Интернет уже появляются сообщения о том, что такие жесткие диски работают всего год-два (разумеется это справедливо для единичных случаев).

     Почитав некоторое число страниц форумов, мне захотелось узнать, как возникает фрагментация файлов и как это явление протекает у различных файловых систем, поэтому решил провести тестирование.
     Как реализовать подобное тестирование? Предположим, имеется жесткий диск небольшой емкости, например, от 256 до 300 Мегабайт. Диск форматируется в желаемую файловую систему, затем туда записывается группа небольших файлов, объемом, скажем 2,5 мегабайт. Затем, создается образ такого диска и анализируется. После ознакомления, более половины файлов удаляются с удерживанием клавиши [Shift] (уничтожение файлов минуя "Корзину").
     Следующая стадия эксперимента включает в себя создание нескольких файлов гораздо большего размера, например 5 файлов по 25 мегабайт. Для того, чтобы проследить порядок расположения файлов в дисковом пространстве, каждый из пяти файлов имеет собственное содержимое. Так, первый файл содержит "двоечки", второй - "3" и так далее. Пятый файл содержит символ "6".

Соответствие объема и типа файла цвету	объем
1	2.5 Mb
2	25 Mb
3	25 Mb
4	25 Mb
5	25 Mb
6	25 Mb
7	100 Mb

     После записи пяти файлов, точно так же создается второй образ диска для анализа. Наконец, удаляются два-три файла объемом 25 мегабайт и частично с десяток файлов по 2,5 мегабайта (содержимое файла - символ единички) и на диск записывается один файл объемом 100 мегабайт, содержащий символ "7". Третий образ жесткого диска также сохраняется и анализируется.

     В результате осуществленных операций, на втором этапе, файлы по 25 мегабайт будут записываться в свободные области диска. Нам интересно знать, будет ли драйвер файловой системы "обдуманно" искать свободные "дыры", или примется заполнять пространство с самого начала диска? На третьем этапе, драйверу предстоит расположить достаточно емкий файл в освобожденное место. В теории файлы по 25 Мбайт уже будут фрагментированными, а 100 Мбайт, практически полностью "распадется" на части.
     Справедливости ради хочется заметить, что я "поставил" файловую систему в трудные условия. По-честному, надо было заполнять по 70% жесткого диска и производя удаления, ожидать, что файловая система будет стремиться не разбивать сохраняемый файл, а все-таки искать свободное место в конце диска. Таким образом, тот драйвер окажется профессиональным, который "думает" прежде чем сохранить файл.

     Программа, которая создается для анализа диска-образа, будет достаточно простой, поэтому дальнейшими исследованиями займется пользователь. В процессе исследования, байт за байтом считываются данные и в зависимости от найденных символов, на экране возникнет графическая карта жесткого диска. Хочется сразу отметить, что изначально не планировалось реализовывать серьезный анализ данных. Программа была написана на Lazarus, поэтому легко компилируется и запускается в операционных системах Ubuntu Linux, Windows и MacOS X. Для экспериментов с HFS+ Apple Macintosh использовался ноутбук PowerBook-G4 и флешка на 256 мегабайт. Подготовленные заранее файлы копировались на отформатированную на Макинтоше флешку средствами MacOS X 10.5.8. Образ "снимал" программой для Windows - "Flashnul" ("http://shounen.ru/soft/flashnul/"). Команда "flashnul f: -S c:\hddimage.img", позволит создать "слепок" флешки "F" в виде файла-образа на диске "C:\" (позже образ был проанализирован в самой MacOS X 10.5.8 с помощью "портированной" программы)
     Если производить чтение данных, заполняя при этом "карту диска" то, понятное дело, точек на мониторе не хватит, чтобы отобразить весь рисунок. В связи с этим, для полученных файлов ставилась одна цветная точка, если будет насчитано 40000 таких одинаковых байт. Таким образом, исходя из выражения 2500000/40000=62.5, на карте будет отображено 62 точки для файла объемом 2,5 мегабайт, 625 точек для файла объемом 25 мегабайт и так далее. Этот параметр не меняется, поскольку объемы тестовых файлов заранее известны и задаются программой defrag-rsrch. Необходимо помнить о том, что на диске присутствует и служебная информация, которую также необходимо фильтровать. В конечном итоге, тестовый образец, написанный за вечер, в последующие дни эксперимента "перерос" в программу, которая позволяет ставить "флажок" в том случае, если "меченый" файл прервется даже на один байт. Регулировка этого параметра управляет выводом карты на экране. И, конечно же, для системной информации карта выглядит неверно, поскольку для абсолютно точных пропорций придется писать сложные подпрограммы, анализирующие огромные массивы считываемых служебных данных. Для тех, кто будет использовать программу самостоятельно, хочется предупредить, что код не помещался в таймер, поэтому прерывание процесса сканирования образа не предусмотрено (диспетчер задач - снять задачу).

     РЕЗУЛЬТАТЫ ТЕСТА.
     Файловая система Fat32 (ОС Windows)
* На представленном рисунке хорошо видно, что в дисковом пространстве, все файлы представляют собой нераздельный поток данных (первая коричневая полоса вверху слева направо). Таким образом, при повреждении таблицы размещений файлов (File Allocation Table), восстановить отдельно взятые файлы практически невозможно, поскольку нет ни начала ни конца.
* Файлы записались успешно, полностью вместившись на диск.

     Файловая система NTFS (ОС Windows)
* После форматирования диска флажок "индексирование файловой системы" (для быстрого поиска файлов) не снимал.
* Согласно рисунку файлы отделяются друг от друга служебной информацией. При потере таблицы размещения файлов, можно "собрать" файл из "обломков", хотя имя файла по-прежнему будет недоступно.
* В центре диска "появилась" область MFT (таблица размещения файлов).
* Файлы записались успешно, полностью вместившись на диск.

     Файловая система HFS+ (ОС MacOS X)
* Форматирование отняло у пользователя до 10 Мегабайт дискового пространства для служебных нужд.
* На рисунке заметна аналогия с FAT32, когда содержимое диска представляет собой непрерывный "кусок" данных. При повреждении FAT документы восстановить можно, но имена файлов, уже нет.
* Файлы записались успешно, полностью вместившись на диск.

     Файловая система Ext3 (ОС Linux)
* При форматировании диска, часть пространства была взята файловой системой для служебных нужд.
* После модификации программы чтения, я заметил, что файл в Ext3 фрагментируется уже изначально. Предположительно это и есть функция журналирования.³ Таким образом, после записи каждых 262144 байт файла, создается служебная информация в размере 1024 байт (иногда 2048 байт).

     То есть при записи на отформатированный диск, файл сразу же разбивается на мельчайшие кусочки, идущие друг за другом. Помимо такого, интересного разделения файла, при отсутствии свободного места, файл традиционно разбивается на заданные драйвером файловой системы фрагменты больших размеров.
* Для записей файлов места не хватило. Причем, после сообщения о нехватке дискового пространства, в системе возникла "неразбериха". При удалении файлов, объем свободного места по-прежнему составлял 0 байт. При удалении файлов в объеме свыше половины общего объема диска, наконец-то "возникло" свободное место.
* При использовании файловой системы Ext3, можно рекомендовать не заполнять диск полностью. Оставлять 500-1000 Мегабайт свободного пространства, а при записи файла следить за тем, чтобы после операции копирования не заполнить диск полностью. В противном случае, необходимо срочное "спасение" данных пользователя и последующее форматирование диска. Файловая система Ext3 очень популярна среди пользователей, но после эксперимента, моментально пропало желание пользоваться ей.

     Файловая система Ext4 (ОС Linux)
* После форматирования у пользователя сразу отнимается 30 Мегабайт для служебных целей (как и в случае с Ext3).
* Свободное место стремительно кончилось, поэтому пришлось удалять огромное число тестовых файлов.

     Файловая система XFS (ОС Linux)
* Форматирование отняло у пользователя всего 30 Кбайт под служебные нужды.
* После удаления первой группы файлов (2,5 Мбайт), в рекомендуемом для следующего этапа объеме, драйвер сообщил о недостаточном свободном месте. Известно, что система XFS бережно относится к жесткому диску, производя запись только в необходимых ситуациях. Пожалуй, можно согласиться, так как последующий равномерный "рост" свободных мегабайт может указывать на такое поведение.
* При нехватке места, драйвер файловой системы XFS, как и положено, сообщил об ошибке, но оставил не до конца записанный файл, что может говорить о недочете системы, а может и преимуществе.

     Файловая система ReiserFS (ОС Linux)
* После форматирования "забрала" 35 Мб.
* Файлы записались успешно, полностью вместившись на диск.

     Файловая система BTRFS (ОС Linux)
* После форматирования, служебная информация заняла всего лишь 40 Килобайт.
* Свободное место закончилось на 84-м по счету файле (2.5 Мбайт * 84). Удалил что мог, освободил место, но при заполнении "двадцать-пятками", последний файл записался частично (с появлением сообщения "Disk Full").
* Заметил, что место после удаленного файла освобождается где-то через секунд 30. Но даже при 163 Мбайт свободного места, файл размером 90 мегабайт уже не создать. Копирование производилось в файловом менеджере Midnight Commander.
* Позже, изменил программу, добавив "желтую восьмерку", чтобы отследить, осталось ли что после удаленного 90 Мбайт файла. "Желтая восьмерка" содержала 100 Мбайт данных и также не прописалась полностью, так что на диск сохранился неполный фрагмент файла.

ЗАКЛЮЧЕНИЕ
     Многие из этих систем оставляют часть файла, которая вместилась на диск до сообщения о нехватке дискового пространства. Однако, поступая более грамотно, файловая система должна спросить пользователя - оставить то, что записалось, или удалить?

     Для "борьбы" с фрагментацией, используют специальные программы-дефрагментаторы. Фрагментация возникает при интенсивном удалении и записи на диск множества файлов. Если пользователь на своем компьютере слушает музыку, смотрит кино и фотографии, изредка набирая текстовые файлы, то выполнение дефрагментации раз в полгода - год, вполне нормальное явление. Иногда, дефрагментацию осуществляют разово, после интенсивных файловых операций, после чего "забывают" о диске на годы.

Программы-дефрагментаторы ОС Windows:
* Встроенная в операционную систему: /Пуск/-/Программы/-/Стандартные/-/Служебные/-Дефрагментация диска.
* Speed Disk (входящая в состав утилит Norton Utilities)
* Defraggler - пожалуй, лучшая.
* SmartDefrag
* Diskeeper
* JkDefrag
* O&O Defrag
и другие

Программы-дефрагментаторы ОС Linux:
* Shake (в настоящее время проект остановлен)
* Одним из способов осуществления дефрагментации в мире Linux считается перенос всех файлов с одного диска на другой, затем форматирование диска и последующий возврат файлов на прежнее место. Для получения информации о количестве фрагментов файлов имеется специальный скрипт (копия).

Программы-дефрагментаторы ОС MacOS X:
* iDefrag
* Stellar Drive Defrag

     Процесс дефрагментации довольно длительный, поэтому чаще ему уделяют ночь, оставляя компьютер включенным (может потребоваться программа "DontSleep!" - сайт). В ОС Windows XP (а также в Windows 7) дефрагментация осуществляется существенно медленней, чем в ОС Windows-95/98/ME. Быть может это связано с переходом на новый драйвер файловой системы, который даже на нежурналируемых дисковых разделах пытается осуществлять задержки при записи файла, повышая тем самым надежность хранения пользовательских данных (интересно, что в Windows 8.1 дефрагментация выполняется быстрее чем в 7 и XP).
     В силу разных причин (например, заблокированные системные файлы, включена система восстановления), дефрагментация может быть выполнена не до конца и это нормальное явление, поэтому причин для беспокойства нет.