Статьи
В статье “Что лучше для восстановления FAT или NTFS?” подводя итоги, мы столкнулись с необходимостью более детально рассмотреть операции создания, изменения файла. Связано это с тем, что более глубокое понимание этих процедур должно привести нас к выбору лучшей файловой системы по критерию “Восстановление данных”.
Для начала проведем тестовый эксперимент по созданию и изменению (увеличение) размера файла, для того чтобы на практике проследить как драйвера файловой системы* FAT32 и NTFS работают с файлами, определим, где возникает наибольшая фрагментация, что серьезно затрудняет восстановление данных. После этого подведем итоги, в которых будут даны рекомендации по выбору файловой системы.
Тестирование проводилось на Microsoft Windows XP. На жестком диске создаем стандартными средствами операционной системы два раздела равного размера 10Гб (равным размер считается вплоть до байта), первый раздел форматируем быстрым форматирование в FAT32 (по умолчанию размер кластера системой выбирается равным 16-ти), второй в NTFS (по умолчанию размер кластера системой выбирается равным 8-ми). Следующим шагом необходимо заполнить полностью каждый из разделов, копируем одинаковые файлы и папки на каждый из них. В связи с тем, что для разделов у нас выбран разный размер кластера, а также специфики каждой файловой системы, у нас не получится заполнить на 100% именно одинаковыми, поэтому добиваемся эффекта, когда каждый из разделов полностью занят (нет свободного пространства). Учитывая то, что у нас производится копирование на чистые разделы, все файлы ложатся нефрагментированными и следуют по порядку друг за другом. Выбираем произвольную папку для анализа, в нашем случае пусть это будет папка с фотографиями (выбор папки с фотографиями не принципиален, рассматривать можно любые другие файлы). Для дальнейшего анализа нам необходимо собрать информацию о размере и местоположении файлов из этой папки (номера и порядок занимаемых кластеров) в каждой файловой системе. Составим таблицу 1, в которую занесем все собранные данные.
Таблица 1.
№
|
Название файла |
Размер файла |
FAT32 |
NTFS |
|
1 |
Img_0027.jpg |
2’114’937 |
5 -> 263 |
1106561 -> 1107077 |
|
2 |
Img_0034.jpg |
3’125’317 |
264 -> 645 |
1107078 -> 1107841 |
|
3 |
Img_0035.jpg |
910’315 |
646 -> 757 |
1107842 -> 1108064 |
|
4 |
Img_0109.jpg |
3’028’489 |
758 -> 1127 |
1108065 -> 1108804 |
|
5 |
Img_0110.jpg |
3’189’799 |
1128 -> 1517 |
1108805 -> 1109583 |
|
6 |
Img_0111.jpg |
3’089’339 |
1518 -> 1895 |
1109584 -> 1110338 |
|
7 |
Img_0112.jpg |
2’630’246 |
1896 -> 2217 |
1110339 -> 1110981 |
|
8 |
Img_0113.jpg |
3’145’289 |
2218 -> 2601 |
1110982 -> 1111749 |
|
9 |
Img_0114.jpg |
2’618’276 |
2602 -> 2921 |
1111750 -> 1112389 |
|
10 |
Img_0117.jpg |
2’573’832 |
2922 -> 3236 |
1112390 -> 1113018 |
Для удобства далее название файла Img_0027.jpg, Img_0034.jpg, Img_0035.jpg, … будем представлять в виде 0027, 0034, 0035 и т.д. Как видно из таблицы, что в FAT32, что в NTFS, файлы лежат друг за дружкой и целиком (Схема 1).
Схема 1
|
… |
0027 |
0034 |
0035 |
0109 |
0110 |
0111 |
0112 |
0113 |
0114 |
0117 |
… |
А теперь проведем маленький фокус: удаляем на каждом из разделов следующие файлы: 0034, 0109, 0111, 0112, 0113, 0114 (Схема 2). Делаем мы это для того, чтобы получить для каждой файловой системы по три свободных фрагмента разной длины (моделируем работу пользователя с файлами).
Схема 2
|
… |
0027 |
|
0035 |
|
0110 |
|
|
|
|
0117 |
… |
В следующей таблице 2 для FAT32 и NTFS подсчитаем размер каждого свободного фрагмента в кластерах, это пригодится нам в дальнейшем при выборе размера создаваемого и изменяемого файла.
Таблица 2
| № |
FAT32 (размер фрагмента) |
NTFS (размер фрагмента) |
|
Первый свободный фрагмент |
382 кластера |
764 кластера |
|
Второй свободный фрагмент |
370 кластеров |
740 кластеров |
|
Третий свободный фрагмент |
1404 кластеров |
2806 кластеров |
Создание файла
Моделируем ситуацию, когда пользователь создает файл и проанализируем, как драйвер каждой из файловых систем его положит на разделе, причем размер файла выбираем таким образом, чтобы он был меньше самого большого свободного фрагмента (целиком мог попасть) и больше остальных свободных фрагментов. Пусть наш созданный файл будет равен 9’043’068 байт. Объясним, почему мы выбрали именно это значение. Составим таблицу 3, в которой укажем, сколько каждый из удаленных файлов занимал кластеров в FAT32 и NTFS.
Таблица 3
№
|
Название файла |
FAT32 |
NTFS |
|
1 |
0034 |
382 |
764 |
|
2 |
0109 |
370 |
740 |
|
3 |
0111 |
378 |
755 |
|
4 |
0112 |
322 |
643 |
|
5 |
0113 |
384 |
768 |
|
6 |
0114 |
320 |
640 |
Не принципиальный момент, но пусть наш создаваемый файл полностью перекрывает размер в кластерах файлов 0111, 0112, 0113 и немного 0114.
Для FAT32: (378+322+384+20)*16*512 = 9’043’968 байт.
Для NTFS: (755+643+768+40)*8*512 = 9’035’776 байт.
За основу берем максимальный из них, то есть 9’043’968 байт.
Теперь наступает один из ключевых моментов, который следует особо выделить: создаем на каждом разделе файл размера 9’043’068 байт и смотрим, как он располагается в FAT32 и NTFS. Получаем следующий результат:
В файловой системе FAT32 файл занимает 3 фрагмента (Схема 3):
264 -> 519 // 1 – й фрагмент
758 -> 1013 // 2 – й фрагмент
1518 -> 2109 // 3 – й фрагмент
Схема 3
FAT32
|
… |
0027 |
1 |
|
0035 |
2 |
|
0110 |
3 |
|
|
|
|
0117 |
… |
В файловой системе NTFS файл лежит одним фрагментом (Схема 4):
1109584 -> 1111791
Схема 4
NTFS
|
… |
0027 |
|
0035 |
|
0110 |
|
1 |
|
|
|
0117 |
… |
Как видно и схемы 3 и схемы 4, драйвер файловой системы NTFS, смог его положить одним фрагментом, в отличие от FAT32, который разорвал файл на куски.
Изменение файла
Исходная позиция, как и при создании файла (Схема 5).
Схема 5
|
… |
0027 |
|
0035 |
|
0110 |
|
|
|
|
0117 |
… |
Создаем файл небольшого размера, например 65536 байт, и посмотрим, куда он ляжет в случае FAT32 (Схема 6) и NTFS (Схема 7). Получаем следующий результат:
В файловой системе FAT32 файл занимает кластера 264 - > 271
Схема 6
FAT32
|
… |
0027 |
1 |
|
0035 |
|
0110 |
|
|
|
|
0117 |
… |
В файловой системе NTFS файл занимает кластера 1008065 - > 1108080
Схема 7
NTFS
|
… |
0027 |
|
0035 |
1 |
|
0110 |
|
|
|
|
0117 |
… |
Из схем 6 и 7 легко видно, что в FAT32 файл лег в первый свободный фрагмент, а в NTFS драйвер его положил в наименьший по размеру фрагмент (размеры фрагментов Таблица 2). Это второй ключевой момент на который стоит обратить внимание, детально будет рассмотрен в итогах. Следующим шагом наращиваем файл до размера 9’043’068 байт и проверяем, что происходит с расположением файла в обоих случаях.
В файловой системе FAT32 файл занимает 3 фрагмента (Схема 8):
264 -> 599 // 1 – й фрагмент
758 -> 1093 // 2 – й фрагмент
1518 -> 1950 // 3 – й фрагмент
Схема 8
FAT32
|
… |
0027 |
1 |
|
0035 |
2 |
|
0110 |
3 |
|
|
|
|
0117 |
… |
Та же ситуация как и при создании файла в FAT32, единственное изменились размеры фрагментов.
В файловой системе NTFS файл занимает 3 фрагмента (Схема 9):
1108081 -> 1108804 // 1 – й фрагмент
1107078 -> 1107841 // 2 – й фрагмент
1109584 -> 1110302 // 3 – й фрагмент
Схема 9
NTFS
|
… |
0027 |
2 |
0035 |
|
1 |
0110 |
3 |
|
|
|
|
0117 |
… |
Как видим, в обоих случаях файл получился фрагментированным, только расположение фрагментов разное. Особо следует отметить, что драйвер файловой системы NTFS оставил на разделе файл до изменения, а изменение файла свелось к созданию нового файла уже с изменениями, который драйвер начал класть сразу же за старым файлом. Причины побудившие поступить именно так драйверу мы будем, возможно, исследовать в следующих статьях.
Вывод:
При создании файла в файловой системе FAT32 драйвер разорвал файл на фрагменты, первая часть файла легла в первый свободный фрагмент и дальше по цепочке. Резонно, будет отметить, что если бы первый фрагмент был больше по размеру, чем создаваемый файл то файл лег бы целиком (одним фрагментом). В файловой системе NTFS драйвер подобрал свободный фрагмент такого размера, куда попадал бы файл целиком.
При изменении файла (увеличение его размера) в файловой системе FAT32 драйвер, как и при создании, разорвал файл, разложив фрагменты в том порядке, в котором встречались свободные участки на разделе. В файловой системе NTFS файл также получился фрагментированным, но при этом сохранилась старая версия файла (тема для дальнейшего анализа). Следует отметить, что в данном тестовом эксперименте мы рассмотрели простой частный случай, в реальности же, все намного сложнее, файлы создаются, дополняются, изменяются и удаляются многократно. Но, при этом, файловая система NTFS менее предрасположена к фрагментации, чем FAT32, так как в ней заложен механизм подбора свободного оптимального по размеру участка под новый файл. Нашими рекомендациями при выборе файловой системы будет NTFS. Единственное следует отметить, что по умолчанию в NTFS, драйвер выбирает размер кластера равным 8-ми секторам (кластер содержит 4096 байт), это значение выбирается из критерия быстродействия и наиболее оптимального использования пространства раздела. Мы же порекомендуем выбирать 64Кб (128 секторов на кластер), в быстродействии пользователь ничего не потеряет, а лишь в оптимальном использовании пространства раздела, но при этом значительно повышается вероятность восстановление данных, в случае их потери.
Рекомендация по критерию восстановление данных: файловая система NTFS с размером кластера 64Кб.
Файлы, с которыми пользователи ведут интенсивную работу, вероятнее всего, будут фрагментированными. Поэтому целесообразна следующая рекомендация:
Файлы, в которые наиболее часто вносятся изменения и являются ценными для пользователя, необходимо, периодически копировать в архивную папку, обязательно на раздел с файловой системой NTFS (копирование для файловой системы это фактически создание нового файла, поэтому драйвер будет ему подыскивать оптимальное местоположение).
* драйвер файловой системы – это управляющая программа, с помощью которой операционная система организовывает данные на разделе.
