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

[Vadikan]

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

Но в этом случае данные сектора размазываются по 16 кластерам, так что даже если сектор и продолжит принадлежать данному файлу, прежних данных в нем уже не будет. »
Логично, а что по поводу декомпрессии файла, который впоследствии не изменялся? ^^

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

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

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

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

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

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

[Vadikan]

К сожалению, точного описания работы сжатия (не самого алгоритма) я так и не смог найти, можно попытаться проверить, но пока других забот хватает.
Кстати, у меня сложилось устойчивое внутреннее убеждение, что если данные 16 кластеров не удалось сжать в 15 или меньше, то эти 16 кластеров пишутся несжатыми. »
Я порылся в интернете на предмет того, откуда у меня отложилась информация о сжатии и нашел Understanding NTFS Compression (http://blogs.msdn.com/b/ntdebugging/archive/2008/05/20/understanding-ntfs-compression.aspx), где как раз подтверждается этот тезис.
If the compression results in a reduction by one or more clusters, the compressed unit will be written to disk in its compressed format.

[piligrimka]

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

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