[решено] Фрагментация при записи на пустой том.

[littlefunnyevil]

Доброго времени суток!
Вчера решил переустановить систему на Win 8.1 x64 и переразбить тома. Решил использовать для этого EaseUS Partition Master. Тома оставил со стандартным размером кластера, а том под игры решил сделать с кластером на 8КБ, т.к. прочитал инфу, что при записи крупных файлов на кластеры бОльшего объёма повысится скорость чтения (верно ли это?? :) ). В итоге при установке игры (папка объёмом 28.9 ГБ, основные файлы - 20шт. по ~1 Гб) вся (!!) записалась фрагментами. Меня это очень удивило. Может кто обьяснит, в чём дело? Спасибо.

[Tau_0]

при записи крупных файлов на кластеры бОльшего объёма повысится скорость чтения (верно ли это?? ). »
В Microsoft считают оптимальный размер кластера = 4 KiB. Но при этом надо форматировать (создавать файловую систему) штатным Format Microsoft Win 8.1 x64.

Кстати версии NTFS для разных Windows различаются..., особенно сильные отличия наблюдаются в Widows 8. Следует учитывать, что и команда чекдиск крутися постоянно и порой может вступать в конфликт даже с ФС, созданной Windows 7. --- Чекает её на свой лад. Может и ФС, созданную EaseUS Partition Master, чекдиск рихтует на свой лад... Вот и получается много Run/отрезков/экстентов для одного файла.

Также учитывайте, что файл в NTFS это не поток байтов, а поток атрибутов файла...

Хотите разобраться --- читайте доку по внутреннему устройству NTFS. Используйте дисковые редакторы: --- DMDE, WinHex, ..., etc и вникайте в тонкости... Я таких исследований не проводил, а только по кусочкам случайно читал...

[misha2]

(папка объёмом 28.9 ГБ, основные файлы - 20шт. по ~1 Гб) вся (!!) записалась фрагментами »
Не удивительно. Файлы пишутся туда, где в данный момент времени спозиционирована головка винта. И понятно что за каждый поворот диска при их вращении головка не может писать всё чётко последовательно и находится физически на том же самом треке. Вот и выходят фрагменты отдельных файлов. Ну и самих головок чаще всего не 1 шт. стоит в винте.

[littlefunnyevil]

O, вот оно как. Ясно. Крайне понятный и исчерпывающий ответ. Спасибо.
p.s. вчера решил провести эксперимент. Ту папку на 28 ГБ скопировал на соседний том и форматнул вышеназванный том со стандартным размером кластера с помощью Виндового format'a. Итог - при копировании папки заново - почти никакой фрагментации.http://i.imgur.com/5Y7Artx.jpg
А уже последующие файлы начали опять получаться фрагментированными.

[piligrimka]

Не удивительно. Файлы пишутся туда, где в данный момент времени спозиционирована головка винта. »
Это предположение или утверждение?
Хотите сказать что операционная система не занимается оптимизацией записи на диск, как об этом декларировано, и как должно быть по логике?
Или речь идёт о новоделе от Microsoft?

[Tau_0]

piligrimka, независимо от самых оптимальных стратегий выделения внешней памяти и использования кэшей, при параллельном чтении/записи многих файлов (а именно так и происходит) фрагментация неизбежна...
Конечно, если каждому файлу предоставить по харду, то фрагментация уменьшится, но только где столько хардов взять...???...

[Игорь Лейко]

верно ли это?? »
Нет.
Итог - при копировании папки заново - почти никакой фрагментации. »
Установка и копирование могут различаются довольно значительно.

[misha2]

утверждение? »
Утверждение. Достачно почитать о работе и устройстве винта и принципе чередования головок, зонном распределении и методах внутренней трансляции (относится уже к программной архитектуре винта).
ОС и занимается этой самой дефрагментацией, правда невсегда эффективно. И понятие "дефрагментация" и есть подтверждение мной сказанного, что файлы неизбежно фрагментируются при записи на поверхность.

[piligrimka]

Tau_0
Фрагментация неизбежна в случае если нет свободного цельного куска, в который можно записать требуемый файл.
Во всех остальных случаях всё пишется целиком - и это наглядно показывают операционки относящиеся к Linux.

misha2
Причём здесь внутренности винта если операционка имеет общение с другим уровнем представления?
Самостоятельно дефрагментацией занимается Виста и оследующие операционки. В ХР это не делалось автоматом и дефрагментация на нормально заполненных разделах практически отсуствовала. По крайней мере для небольших файлов. Означает ли это что более новые операционки, зная о том что потом будет дефрагментация, пишут где прийдётся, без всякой оптимизации?

[misha2]

Причём здесь внутренности винта если операционка имеет общение с другим уровнем представления? »
А винту пофик виндовые и Осёвые представления. Он пишет туда куда спозиционированы головы в данную миллисекунду.
А винда не может указывать винту куда именно и по какому ЛБА писать данный файл. Винт это решает сам. И без вашего внешнего участия. Это потом вы можете повлиять на расположение фрагментов - лишь когда файл уже полностью записан. Тогда у ж сам дефрагментатор решает нужно дефрагментировать тот файл или нет.

[Игорь Лейко]

А винту пофик виндовые и Осёвые представления. Он пишет туда куда спозиционированы головы в данную миллисекунду. »
Логично. Писать на дорожку, над которой не висят головы, винт не умеет. :)
А винда не может указывать винту куда именно и по какому ЛБА писать данный файл. »
Может и указывает.

[Tau_0]

Фрагментация неизбежна в случае если нет свободного цельного куска, в который можно записать требуемый файл. »
Вы не учли того, что модификация/изменение ранее созданного файла (пусть ранее он не был фрагментированным) неизбежно ведёт к его фрагментации, и не только его.

Хотя у Linux и Windows разные файловые системы, но и файлы Linux тоже фрагментируются…

[Игорь Лейко]

и это наглядно показывают операционки относящиеся к Linux »
Линукс во многих отношениях сделан правильнее, чем Windows, а Windows - оптимальнее чем линукс.

Вы не учли того, что модификация/изменение ранее созданного файла (пусть ранее он не был фрагментированным) неизбежно ведёт к его фрагментации, и не только его. »
Насчет неизбежности в Windows Вы несколько погорячились.

[mwz]

Вы не учли того, что модификация/изменение ранее созданного файла (пусть ранее он не был фрагментированным) неизбежно ведёт к его фрагментации, и не только его. »

1. Если при модификации размер файла не увеличивается (и даже если увеличивается, но не переходит за границу последнего кластера файла) -- фрагментация файла не меняется.

2. Запись, в т.ч. модификация одного файла не может привести к повышению фрагментации другого уже записанного.

3. По ряду положений, в т.ч. высказанных misha2, в дискуссию вступать не хочу, хотя руки и чешутся; поскольку произошёл переход от понятия "логическая фрагментация" (которую показывает в т.ч. Windows) к понятию "физическая фрагментация" (расположению файла на диске: да, дефрагментированный с точки зрения Windows и других программ дефрагментации файл может "физически" располагаться даже на разных блинах).

[misha2]

Может и указывает. »
А мож не по ЛБА, а по INDX ? Ведь это как раз её прерогатива знать какие заняты.
модификация/изменение ранее созданного файла (пусть ранее он не был фрагментированным) неизбежно ведёт к его фрагментации »
И схранение одного и того же файла, например в ворде создаст его новую копию в другом физически месте и будет присвоен новый INDX. Если б винда умела обращаться по ЛБА впрямую, то при анализе доступного пространства ЛБА винта и восстановлении файлов мы б не видели дубликатов одного и того же файла в разных физически местах.

[mwz]

И сохранение одного и того же файла, например в ворде создаст его новую копию в другом физически месте »

Ну так это не операционка "виновата" -- а Word. Который не заменяет файл по месту, а создаёт новый, удаляет старый и переименовывает новый.

Очень хорошо такие моменты проявляются при работе с копиями в виде жёстких ссылок (hardlinks): если после работы с такой ссылкой файл стал независимым -- то произошла не модификация файла, а создание нового с удалением старого (пример -- модификация RAR-архива). А при правке, например, текстовых файлов с помощью Akelpad жёсткие ссылки не теряются, т.е. происходит модификация "по месту".

[Игорь Лейко]

А мож не по ЛБА, а по INDX ? »
Что Вы имеете в виду под INDX? Что-то я ничего похожего в командах ATA не могу найти. :(

[misha2]

произошёл переход от понятия "логическая фрагментация" (которую показывает в т.ч. Windows) к понятию "физическая фрагментация" (расположению файла на диске »
И то, и то есть логическая фрагментация в отношении указанных ЛБА. Всё равно доступ к файлам организуется по ЛБА через индексы. Про адресацию в PCHS бессмысленно говорить, т.к. это делается за счёт трансляции винта и только винту это ведомо. Никак не ОС.
Поэтому если говорить о фрагментации в этой теме, то только о логической.
Что-то я ничего похожего в командах ATA не могу найти »
Потому что это относится к MFT, а не к АТА-стандарту.

[Игорь Лейко]

Потому что это относится к MFT, а не к АТА-стандарту. »
Значит, никак не относится к диску. Он про MFT ничего не знает. Для него она - точно такие же секторы, как и любые другие. Велели записать - запишет, велели прочитать - прочтет. А что там эти байты означают - не в его компетенции.

[mwz]

Поэтому если говорить о фрагментации в этой теме, то только о логической »

О чём я и сказал: что произошёл переход от логической к физической фрагментации.
Поскольку вопрос был "почему файлы стали фрагментированными" -- и ответ что "на диске файлы всегда фрагментированы" не имеет к этому никого отношения.