Использование больших дисков и больших секторов в Windows 8

NTFS — очень экономная система. Размер кластеров в ней разумно минимален — обычно это 4 кб . Как известно, система сильнее всего фрагментирует файлы, когда свободное место кончается, когда приходится использовать мелкие дырки, оставшиеся от других файлов. Тут возникает первое свойство NTFS, которое прямо способствует серьезной фрагментации.
Диск NTFS поделен на две зоны. В начале диска идет MFT зона — зона, куда растет MFT, Master File Table. Зона занимает минимум 12% диска, и запись данных в эту зону невозможна. Это сделано для того, чтобы не фрагментировался хотя бы MFT. Но когда весь остальной диск заполняется — зона сокращается ровно в два раза. И так далее. Таким образом, мы имеем не один заход окончания диска, а несколько. В результате если NTFS работает при диске, заполненном на около 90% — фрагментация растет как бешенная.
Попутное следствие — диск, заполненный более чем на 88%, дефрагментировать почти невозможно — даже API дефрагментации не может перемещать данные в MFT зону. Может оказаться так, что у нас не будет свободного места для маневра.
Далее. NTFS работает себе и работает, и всё-таки фрагментируется. Этому способствует странный алгоритм нахождения свободного места — второе серьезное упущение. Если файл пишется большими кусками — всё нормально. Но если файл медленно растет — алгоритм такой: берется какой-то определенный объем диска и заполняется файлом до упора. Причем по очень интересному алгоритму: сначала заполняются большие дырки, потом маленькие. Т.е. типичное распределение фрагментов файла по размеру на фрагментированной NTFS выглядит так (размеры фрагментов):
16 — 16 — 16 — 16 — 16 — [скачек назад] — 15 — 15 — 15 — [назад] — 14 — 14 — 14 … 1 — 1 — 1 -1 — 1…
Так процесс идет до самых мелких дырок в 1 кластер, несмотря на то, что на диске наверняка есть и гораздо более большие куски свободного места... Что, естественно, способствует большей фрагментации.
В NT существует стандартная API дефрагментация. Обладающая интересным ограничением для перемещения блоков файлов: за один раз можно перемещать не менее 16 кластеров , причем начинаться эти кластеры должны с позиции, кратной 16 кластерам в файле. В общем, операция осуществляется исключительно по 16 кластеров. Следствия:
В дырку свободного места менее 16 кластеров нельзя ничего переместить (кроме сжатых файлов, но это тонкости).
Файл, будучи перемещенный в друге место, оставляет после себя «временно занятое место», дополняющее его по размеру до кратности 16 кластерам.
При попытке некоректно («не кратно 16») переместить файл, результат часто непредсказуем. Что-то округляется, что-то просто не перемещается. Тем не менее, всё место действия щедро рассыпается «временно занятым местом». Наверное, о нас заботятся, чтобы мы отстали от этого места — чтобы алгоритм дефрагментации не клинило.
«Временно занятое место» освобождается через некоторое время, обычно где-то пол минуты. Гы.
Тем не менее, логично было бы использовать это API. Его и используют. Поэтому процесс стандартной дефрагментации, с поправками на ограниченность API, идет следующими фазами, не обязательно в этом порядке:
Вынимание файлов из MFT зоны. Не специально — просто обратно туда их положить не представляется возможным. Безобидная фаза, и даже в чем-то полезная.
Дефрагментация файлов. Безусловно, полезный процесс, несколько правда осложняемый ограничениями кратности перемещений — файлы часто приходится перекладывать сильнее, чем это было бы логично сделать по уму.
Дефрагментация MFT, виртуалки ( pagefile.sys ) и каталогов. Возможна через API только в Windows2000, иначе — при перезагрузке, отдельным процессом, как в Diskeeper-е.
Складывание файлов ближе к началу — так называемая дефрагментация свободного места. Вот это — воистину страшный процесс…
Допустим, мы хотим положить файлы подряд в начало диска. Кладем один файл. Он оставляет хвост занятости дополнения до кратности 16. Кладем следующий — после хвоста, естественно. Через некоторое время, по освобождению хвоста, имеем дырку

Есть в наличии, я использую ))