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

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

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

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

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

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

Не удивительно. Файлы пишутся туда, где в данный момент времени спозиционирована головка винта. И понятно что за каждый поворот диска при их вращении головка не может писать всё чётко последовательно и находится физически на том же самом треке. Вот и выходят фрагменты отдельных файлов. Ну и самих головок чаще всего не 1 шт. стоит в винте.

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

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

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

Нет.
Установка и копирование могут различаются довольно значительно.

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

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

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

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

Логично. Писать на дорожку, над которой не висят головы, винт не умеет. :)
Может и указывает.

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

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

Линукс во многих отношениях сделан правильнее, чем Windows, а Windows - оптимальнее чем линукс.

Насчет неизбежности в Windows Вы несколько погорячились.

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

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

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

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

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

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

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

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

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

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

Потому что на вопрос "почему файлы стали.." был и ответ - потому что файлы пишутся туда где в данный момент находится БМГ винта. И далее....А присваивать индекс местонахождения файла, чтоб знать где он расположен - дело ОС.
Так что "файлы при записи как правило становятся фрагментированы" наиболее уместно. Особенно если учесть что винт дисковое многоголовое устройство, а не магнитофонная лента с линейной записью.

Это была не просто запись файлов (которая происходит в частности при копировании), а работа установщика, который распаковывает файлы не запрашивая у Windows выделения места под файл целиком. Если бы запросило (примерно что и происходит при копировании: Windows сначала выделяет место под файл, а затем уже копирует туда) -- то было бы не фрагментировано (если бы на диске были подходящие участки; иначе -- слабофрагментировано).

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

Кроме того, "файлы пишутся туда где в данный момент находится БМГ винта"... А если головка находится над местом, где лежит файл? Таки сначала запрос обрабатывается Windows, которая смотрит куда можно разместить данный кусок, если ему не было заранее выделено место.

То есть размечает и вносит записи индексов в MFT, не так ли ?
А вот в записях можно уже поместить номера ЛБА, пространство в ЛБА (от n- до n+xxxx), правда ж ?
Выходит винда работает со своей индексацией, а ЛБА-пространство вторично для неё.
А то как быть тогда с копированием папок и файлов на винт/раздел другого обьёма ? Там и МФТ то другая. Впрямую по номерам ЛБА то не выйдет...
Для этого и существуют индексные записи и карта занятого/незанятого пространств. Это всё речь об обработке виндовсом. А речь реально шла о размещении файлов и их фрагментации при этом самом размещении. И винда тут причём конечно, т.к. она инициатор присваивания индексов, записей в МФТ и прочая-прочая... Но управлять именно чётким расположением в ЛБА-пространстве полностью она не может. (Поэтому и придуманы меры онлайн-дефрагментации). Иначе б в природе исчезло бы (и никогда б не было) понятия фрагментации.

Вообще то Windows на уровне кластеров, а не секторов, хотя Бох его знает, как там драйвер I/O устроен.

В NTFS у файла есть атрибут атрибут $INDEX_ROOT, но он для внутренних потребностей Windows предназначен. А на другом харде будет по-другому --- сильно фрагментированный файл может стать нефрагментированным или наоборот --- от свободного места на другом томе это зависит …. А том/раздел может быть и на том же харде.

Ну мы ж и говорим о внутренних возможностях винды.
Вот-вот и я ж о том. Потому что сам винт пишет эти самые файлы, а не винда их располагает как надо и сразу.

Если при открытии вновь создаваемого файла Windows не знает его размер (файл "из воздуха" может создаваться...), то выделяет ему по дефолту некий экстент, и другим файлам тоже, а потом добавляет по мере надобности другие. Когда файлов много, то они растут и друг друга фрагментируют. Это я и имел в виду, когда первый раз писал.

А mwz полностью расписал --- когда файл копируется, то Windows его размер знает (сложит все экстенты этого файла и получит размер), поэтому заранее для него точный размер зарезервирует. Постарается одним экстентом под него место выделит, если такая возможность есть...

Да, пишет диск (винда сама не умеет). Но Винда даёт команду диску, в какие LBA и что писать: самому-то диску-то наплевать, где у него что лежит и куда писать, не тот у него уровень в иерархии.

По принципу:
"Я -- метатель молота.
Приказано метать -- и я мечу."
(с) В.Высоцкий

Мне думается всё же - "с какого ЛБА" (незанятого) ближе будет.

Вообще-то Windows пишет блоками - и размер этих блоков с размером кластеров никак не связан.
Винт не пишет никаких файлов, он про файлы ничего не знает. Он пишет отдельные секторы или группы секторов. Сказали ему - такой-то блок данных разместить по такому-то LBA - он и выполняет.
Больше того, на нижнем уровне драйвера файловой системы даже сама Windows не знает, какому файлу принадлежит тот или иной блок.

Не факт. И уж тем более -- если речь о выделении заданного пространства.

Но это уже надо знать алгоритмы, заложенные в Windows (да и в Линух, BeOs и т.д.: у каждого разработчика свой подход, как [разумно, в т.ч. без избыточных потерь времени] выделить место так, чтобы при последующем добавлении или удалении файлов снизить вероятность фрагментации новых файлов).

Там алгоритм не особенно простой и не описанный. Простой алгоритм был только в DOS.

Да, пожалуй Вы правы...:), но тогда блок связан с размером сектора.
--- Вычитал у М. Русиновича См.

Ну да, винт же не может записать только часть сектора. Минимальная единица чтения-записи - сектор.

Первое предложение игнорируйте. Очередной случай, когда он не сумел внятно выразить свою мысль. :(

О, раз все гуру собрались, у меня есть вопрос на засыпку :) Допустим, есть файл, и точно известен номер сектора диска, в который он записан (или по крайней мере его фрагмент).

Файл не:
открывался
изменялся
редактировался
копировался
перезаписывался
переносился
делился
почковался :)

В результате каких операций номер сектора может измениться?

Формулировку вопроса уточните, будьте так любезны. ;)
Ибо, например, процесс дефрагментации можно считать переносом файла, а можно и не считать.

В результате дефрагментации -- в т.ч. фоновой.

Дефрагментация слишком очевидно. А вот по такой причине, как появление плохо читаемых клаcтетеров (секторов) сама NTFS может безо всякого чекдиска перенести отдельные Run/отрезки или какие-то кластеры в другое место. Ведь вроде в $BadClus плохие кластеры помещаются и без чекдиска...???...

Эксперимент на обычном диске провести все никак не соберусь, а во "внутреннем устройстве" описано мутновато и другими путями точную информацию получить не удалось. В ряде ситуаций это возможно, но уверенности, что это будет происходить на любом диске и любом контроллере у меня нет.
Впрочем, chkdsk /r и плохой сектор вполне под условия Вадима подходят.
Сжатие-расжатие файла могут подойти, а могут и нет - опять-таки формулировка вопроса расплывчата. То ли "данные этого сектора окажутся в другом секторе", то ли "этот сектор уже не будет принадлежать данному файлу".

Я даже не сомневался, что формулировка не устроит и уверен, что после уточнения она тоже будет негодной :) Подразумевается прямое взаимодействие пользователя с файлом с помощью прикладных программ, например, редактор для этого типа файлов или файловый менеджер. Но при желании запущенную пользователем дефрагментацию тоже сюда можно записать :)

С дефрагом понятно, отсюда и выбор темы для вопроса. Интересуют другие варианты. chkdsk при наличии поврежденного сектора - да. А еще что-нибудь?

Гм... по-моему, при дефраге верно оба, если я правильно понимаю формулировку второго варианта :)

По поводу сжатия. Если файл сжимался, как я понимаю, декомпрессия выполняется в память, а в ФС резервируется пространство, необходимое для записи распакованного файла (точнее, compression unit'а). Но если файл не изменялся после декомпрессии, он разве записывается в ФС заново, оказываясь в другом секторе?

Да, конечно. Или оба неверны, если файл не затронут.
Автоматическое выполнение дефрагментации, внесенное пользователем в планировщик и запущенное планировщиком - это прямое взаимодействие пользователя или непрямое?

Сжатие файла - тоже прямое взаимодействие. :)
Но в этом случае данные сектора размазываются по 16 кластерам, так что даже если сектор и продолжит принадлежать данному файлу, прежних данных в нем уже не будет.

Давай оставим эту затею, тем более что к теме она имеет весьма отдаленное отношение. ;)

Вот именно, поэтому идеальную формулировку придумать затруднительно. Не надо на ней концентрироваться, это не продуктивно... Лучше задавать уточняющие вопросы по конкретным процессам, протекающим в ОС.

Логично, а что по поводу декомпрессии файла, который впоследствии не изменялся? ^^

ТС получил исчерпывающий ответ. В качестве модератора форума я разрешаю дальнейшее обсуждение технических аспектов, связанных с моим вопросом ;)

К сожалению, точного описания работы сжатия (не самого алгоритма) я так и не смог найти, можно попытаться проверить, но пока других забот хватает.
Кстати, у меня сложилось устойчивое внутреннее убеждение, что если данные 16 кластеров не удалось сжать в 15 или меньше, то эти 16 кластеров пишутся несжатыми. Если Tau_0, misha2 или кто-то другой согласятся потратить время на экспериментальную проверку, я буду им искренне признателен.

Ну так в нем сжатые данные восстанавливаются, так что содержимое секторов опять-таки будет изменено, даже если секторы останутся принадлежать этому файлу. Но опять-таки надо проверить, как будет вести себя расжатие.

По поводу сжатия. Похоже, надо будет учитывать версию ОС.
Взял сейчас в Win8 для пробы отлично сжимающийся файл размером (на диске) 2.220.032 байта, выполнил сжатие, и вместо ожидавшихся 34 фрагментов (2220032 / 4096 /16) получил два.
А размер файла вместо ожидавшихся 34 кластеров оказался равным 68.
Надо ковырять вглубь. :(

Я порылся в интернете на предмет того, откуда у меня отложилась информация о сжатии и нашел Understanding NTFS Compression, где как раз подтверждается этот тезис.

Ничего себе, куда вы тему перекинули. Еле нашёл.
Так всё таки, на чём остановились и где решение того, почему у автора происходит фрагментация?

Что то это идёт в разрез с тем, что винт пишет туда, где располагаются головки.
:o Представил что головки находятся в зоне расположения другого логического раздела. :o