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

[misha2]

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

[mwz]

потому что файлы пишутся туда где в данный момент находится БМГ винта »

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

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

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

[misha2]

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

[Tau_0]

А то как быть тогда с копированием папок и файлов на винт/раздел другого обьёма ? Там и МФТ то другая. Впрямую по номерам ЛБА то не выйдет... »
Вообще то Windows на уровне кластеров, а не секторов, хотя Бох его знает, как там драйвер I/O устроен.

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

[misha2]

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

[Tau_0]

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

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

[mwz]

Потому что сам винт пишет эти самые файлы, а не винда их располагает как надо и сразу »

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

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

[misha2]

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

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

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

[mwz]

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

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

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

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

Мне думается всё же - "с какого ЛБА" (незанятого) ближе будет. »
Там алгоритм не особенно простой и не описанный. Простой алгоритм был только в DOS.

[Tau_0]

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

Внутренне NTFS работает только с кластерами. (Однако NTFS инициирует низкоуровневые операции ввода-вывода на томе, выравнивая передаваемые данные по размеру сектора и подгоняя их объем под значение, кратное размеру секторов.) NTFS использует кластер как единицу выделения пространства для поддержания независимости от размера физического сектора. Это позволяет NTFS эффективно работать с очень большими дисками, используя кластеры большего размера, и поддерживать нестандартные диски с размером секторов, отличным от 512 байт.

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

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

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

[Vadikan]

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

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

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

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

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

[mwz]

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

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

[Tau_0]

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

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

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

[Vadikan]

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

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

То ли "данные этого сектора окажутся в другом секторе", то ли "этот сектор уже не будет принадлежать данному файлу". »
Гм... по-моему, при дефраге верно оба, если я правильно понимаю формулировку второго варианта :)

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

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

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

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

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