В вычислительной технике фрагментация файловой системы , иногда называемая старением файловой системы , представляет собой тенденцию файловой системы размещать содержимое файлов непостоянно, чтобы обеспечить возможность изменения их содержимого на месте. Это особый случай фрагментации данных . Фрагментация файловой системы отрицательно влияет на время поиска в вращающихся носителях данных, что, как известно, снижает пропускную способность . Фрагментацию можно устранить путем реорганизации файлов и свободного пространства обратно в смежные области, процесс называется дефрагментацией .
Твердотельные накопители не ищут физически, поэтому их непоследовательный доступ к данным в сотни раз быстрее, чем у движущихся дисков, что делает фрагментацию менее важной проблемой. Рекомендуется не дефрагментировать твердотельные накопители вручную, поскольку это может преждевременно изнашивать диски из-за ненужных операций записи-стирания. [1]
Когда файловая система впервые инициализируется на разделе , она содержит только несколько небольших внутренних структур и в остальном представляет собой один непрерывный блок пустого пространства. [a] Это означает, что файловая система может размещать вновь созданные файлы в любом месте раздела. В течение некоторого времени после создания файлы могут быть расположены почти оптимально. Когда операционная система и приложения устанавливаются или архивы распаковываются, отдельные файлы в конечном итоге появляются последовательно, поэтому связанные файлы располагаются близко друг к другу.
По мере удаления или усечения существующих файлов создаются новые области свободного пространства. При добавлении к существующим файлам часто невозможно возобновить запись именно там, где файл заканчивался, так как там уже может быть выделен другой файл; таким образом, необходимо выделить новый фрагмент. С течением времени и при постоянном наличии одних и тех же факторов свободное пространство, а также часто добавляемые файлы имеют тенденцию фрагментироваться больше. Более короткие области свободного пространства также означают, что файловая система больше не может выделять новые файлы непрерывно и должна разбивать их на фрагменты. Это особенно актуально, когда файловая система заполняется и большие непрерывные области свободного пространства недоступны.
Следующий пример является упрощением сложного предмета. Рассмотрим следующий сценарий: на новом диске было пять файлов с именами A, B, C, D и E, сохраненных непрерывно и последовательно в указанном порядке. Каждый файл использует 10 блоков пространства. (Здесь размер блока не важен.) Оставшееся дисковое пространство — один свободный блок. Таким образом, после файла E можно создавать и сохранять дополнительные файлы.
Если файл B удаляется, создается вторая область из десяти блоков свободного пространства, и диск становится фрагментированным. Пустое пространство просто остается там, помеченное как и доступное для последующего использования, а затем снова используется по мере необходимости. [b] Файловая система может дефрагментировать диск сразу после удаления, но это приведет к серьезному снижению производительности в непредсказуемые моменты времени.
Теперь новый файл с именем F, которому требуется семь блоков пространства, может быть помещен в первые семь блоков недавно освобожденного пространства, ранее содержавшего файл B, и три блока, следующие за ним, останутся доступными. Если будет добавлен еще один новый файл с именем G, которому требуется всего три блока, он может занять пространство после F и перед C.
Если впоследствии F необходимо расширить, так как пространство, следующее непосредственно за ним, занято, есть три варианта для файловой системы:
Второй вариант, вероятно, непрактичен по соображениям производительности, как и третий, когда файл очень большой. Третий вариант невозможен, когда нет ни одного непрерывного свободного пространства, достаточно большого для хранения нового файла. Таким образом, обычная практика заключается в том, чтобы просто создать экстент где -то в другом месте и присоединить новый экстент к старому.
Материал, добавленный в конец файла F, будет частью того же экстента. Но если материала так много, что после последнего экстента нет места, то придется создать еще один экстент и т. д. В конце концов файловая система имеет свободные сегменты во многих местах, и некоторые файлы могут быть распределены по многим экстентам. Время доступа к этим файлам (или ко всем файлам) может стать чрезмерно долгим.
Некоторые ранние файловые системы не могли фрагментировать файлы. Одним из таких примеров была файловая система Acorn DFS , используемая на BBC Micro . Из-за ее неспособности фрагментировать файлы время от времени появлялось сообщение об ошибке can't extend , и пользователь часто не мог сохранить файл, даже если на диске было достаточно места для него.
DFS использовала очень простую структуру диска, и файлы на диске располагались только по их длине и начальному сектору. Это означало, что все файлы должны были существовать как непрерывный блок секторов, и фрагментация была невозможна. Используя пример в таблице выше, попытка расширить файл F на шаге пять потерпела бы неудачу в такой системе с сообщением об ошибке can't extend . Независимо от того, сколько свободного места могло оставаться на диске в целом, расширить файл данных было невозможно.
Стандарты обработки ошибок в то время были примитивными, и в любом случае программы, втиснутые в ограниченную память BBC Micro, редко могли позволить себе тратить пространство, пытаясь изящно обработать ошибки. Вместо этого пользователь оказывался выброшенным обратно в командную строку с сообщением Can't extend , и все данные, которые еще не были добавлены в файл, были бы потеряны. Проблему нельзя было решить простой проверкой свободного места на диске заранее. Хотя свободное место на диске может существовать, размер самого большого непрерывного блока свободного места не был сразу очевиден без анализа чисел, представленных каталогом диска, и поэтому ускользал от внимания пользователя. Кроме того, почти все пользователи DFS ранее использовали кассетное хранилище файлов , которое не страдает от этой ошибки. Обновление до системы с гибкими дисками было дорогим обновлением, и было шоком, что обновление могло без предупреждения привести к потере данных . [2] [3]
Фрагментация файловой системы может происходить на нескольких уровнях:
Фрагментация отдельных файлов происходит, когда один файл разбивается на несколько частей (называемых экстентами в файловых системах на основе экстентов). Хотя дисковые файловые системы пытаются сохранять отдельные файлы смежными, это часто невозможно без значительных потерь производительности. Инструменты проверки и дефрагментации файловой системы обычно учитывают только фрагментацию файлов в своей статистике «процент фрагментации».
Фрагментация свободного (нераспределенного) пространства происходит, когда есть несколько неиспользуемых областей файловой системы, куда можно записать новые файлы или метаданные. Нежелательная фрагментация свободного пространства обычно вызывается удалением или усечением файлов, но файловые системы также могут намеренно вставлять фрагменты («пузыри») свободного пространства, чтобы облегчить расширение соседних файлов (см. предотвращение фрагментации ниже).
Сегментация файлов, также называемая фрагментацией связанных файлов или фрагментацией на уровне приложений (файлов), относится к отсутствию локальности ссылок (в пределах носителя хранения) между связанными файлами. В отличие от предыдущих двух типов фрагментации, разброс файлов является гораздо более расплывчатым понятием, поскольку он сильно зависит от схемы доступа конкретных приложений. Это также делает объективное измерение или оценку его очень сложным. Однако, возможно, это наиболее критический тип фрагментации, поскольку исследования показали, что наиболее часто используемые файлы, как правило, невелики по сравнению с доступной пропускной способностью диска в секунду. [4]
Чтобы избежать фрагментации связанных файлов и улучшить локальность ссылок (в данном случае называемую непрерывностью файлов ), необходимо сделать предположения или активные наблюдения за работой приложений. Очень часто делается предположение, что стоит хранить файлы меньшего размера в одном каталоге вместе и размещать их в естественном порядке файловой системы. Хотя это часто разумное предположение, оно не всегда выполняется. Например, приложение может читать несколько разных файлов, возможно, в разных каталогах, в том же порядке, в котором они были записаны. Таким образом, файловая система, которая просто упорядочивает все записи последовательно, может работать быстрее для данного приложения.
Каталоги или индексы, используемые самой файловой системой, также могут со временем стать фрагментированными, поскольку записи, которые они содержат, создаются, изменяются или удаляются. Это вызывает больше беспокойства, когда том содержит множество очень маленьких файлов, чем когда том заполнен меньшим количеством больших файлов. В зависимости от конкретной конструкции файловой системы файлы или регионы, содержащие эти данные, также могут стать фрагментированными (как описано выше для «обычных» файлов), независимо от какой-либо фрагментации фактических записей данных, поддерживаемых в этих файлах или регионах. [5]
Для некоторых файловых систем (таких как NTFS [c] и HFS / HFS Plus [6] ) сопоставление / сортировка / сжатие, необходимые для оптимизации этих данных, не могут легко выполняться во время использования файловой системы. [7]
Фрагментация файловой системы более проблематична для жестких дисков потребительского класса из-за растущего несоответствия между последовательной скоростью доступа и задержкой вращения (и в меньшей степени временем поиска ), на которых обычно размещаются файловые системы. [8] Таким образом, фрагментация является важной проблемой в исследовании и проектировании файловых систем. Сдерживание фрагментации зависит не только от формата файловой системы на диске, но и в значительной степени от ее реализации. [9] Фрагментация файловой системы оказывает меньшее влияние на производительность твердотельных накопителей , поскольку не требуется механического времени поиска . [10] Однако файловая система должна хранить дополнительные метаданные для каждой несмежной части файла. Каждая часть метаданных сама по себе занимает место и требует вычислительной мощности и процессорного времени. Если достигается максимальный предел фрагментации, запросы на запись не выполняются. [10]
В простых бенчмарках файловых систем фактор фрагментации часто опускается, поскольку реалистичное старение и фрагментацию трудно смоделировать. Вместо этого, для простоты сравнения, бенчмарки файловых систем часто запускаются на пустых файловых системах. Таким образом, результаты могут сильно отличаться от реальных шаблонов доступа. [11]
Для борьбы с фрагментацией было разработано несколько методов. Обычно их можно разделить на две категории: упреждающие и ретроактивные . Из-за сложности прогнозирования шаблонов доступа эти методы чаще всего являются эвристическими по своей природе и могут снижать производительность при неожиданных рабочих нагрузках.
Методы упреждения пытаются свести фрагментацию к минимуму во время записи данных на диск. Самый простой из них — это добавление данных к существующему фрагменту на месте, где это возможно, вместо выделения новых блоков новому фрагменту.
Многие из современных файловых систем пытаются заранее выделять более длинные фрагменты или фрагменты из разных фрагментов свободного пространства, называемые экстентами, для файлов, к которым активно присоединяются данные. Это в значительной степени позволяет избежать фрагментации файлов, когда одновременно присоединяются несколько файлов, тем самым избегая их чрезмерного переплетения. [9]
Если известен окончательный размер файла, подлежащего изменению, хранилище для всего файла может быть предварительно выделено. Например, файл подкачки Microsoft Windows (файл подкачки) может динамически изменяться в процессе нормальной работы и, следовательно, может стать сильно фрагментированным. Этого можно избежать, указав файл подкачки с теми же минимальным и максимальным размерами, фактически предварительно выделяя весь файл.
BitTorrent и другие одноранговые приложения для обмена файлами ограничивают фрагментацию, заранее выделяя все необходимое для файла пространство при начале загрузки . [12]
Сравнительно недавней техникой является отложенное выделение в XFS , HFS+ [13] и ZFS ; та же техника также называется allocate-on-flush в reiser4 и ext4 . Когда файловая система записывается, блоки файловой системы резервируются, но расположение конкретных файлов еще не установлено. Позже, когда файловая система вынуждена сбрасывать изменения в результате нехватки памяти или фиксации транзакции, распределитель будет иметь гораздо лучшие знания о характеристиках файлов. Большинство файловых систем с этим подходом пытаются сбрасывать файлы в одном каталоге непрерывно. Предполагая, что несколько чтений из одного каталога являются обычным явлением, локальность ссылок улучшается. [14] Reiser4 также упорядочивает расположение файлов в соответствии с хэш-таблицей каталога , так что когда файлы доступны в естественном порядке файловой системы (как диктует readdir ), они всегда читаются последовательно. [15]
Ретроактивные методы пытаются уменьшить фрагментацию или негативные последствия фрагментации после того, как она произошла. Многие файловые системы предоставляют инструменты дефрагментации , которые пытаются переупорядочить фрагменты файлов, а иногда также уменьшить их разброс (т. е. улучшить их непрерывность или локальность ссылок ), сохраняя либо файлы меньшего размера в каталогах , либо в деревьях каталогов, либо даже последовательности файлов близко друг к другу на диске.
Файловая система HFS Plus прозрачно дефрагментирует файлы размером менее 20 МБ , разбитые на 8 или более фрагментов, при открытии файла. [16]
Устаревшая Commodore Amiga Smart File System (SFS) дефрагментировала себя во время использования файловой системы. Процесс дефрагментации практически полностью не имеет состояния (кроме местоположения, в котором он работает), поэтому его можно останавливать и запускать мгновенно. Во время дефрагментации обеспечивается целостность данных как для метаданных, так и для обычных данных.
{{cite journal}}: Цитировать журнал требует |journal=( помощь ){{cite journal}}: CS1 maint: неподходящий URL ( ссылка )