Предотвращение крайней фрагментации сжатых образов системы в NTFS

Question

Объяснение проблемы

Я храню образы дисков Windows, созданные с помощью wbadmin, на диске NTFS, и я обнаружил, что сжатие, а затем сжатие NTFS обеспечивает сохранение пространства в 1,5–2 раза, при этом обеспечивая полную доступность для восстановления.

Но в процессе сжатия файл становится безумно фрагментированным, обычно более 100 000 фрагментов для образа системного диска.

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

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

Вопрос

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

Замечания на основе комментариев / ответов:

1. Внешние (для ядра Windows) инструменты сжатия не подходят в моем случае. Они не могут распаковать файл на лету (для распаковки файла 10 Гб мне нужно 10 Гб свободного места, что не всегда под рукой; к тому же, это занимает много времени); они не доступны, когда система загружается с DVD для восстановления (это именно то, когда мне нужно изображение доступно). Пожалуйста, прекратите предлагать их, если они не создадут трансверсально сжатые файлы на NTFS , такие как compact.exe .
2. Сжатие NTFS не так уж плохо для системных образов. Это довольно хорошо, за исключением фрагментации. Кроме того, распаковка не занимает много времени ЦП, тем не менее, уменьшая узкие места ввода-вывода, что в соответствующих случаях повышает производительность (не фрагментированный сжатый файл со значительным соотношением).
3. Утилиты дефрагментации дефрагментируют файлы, не обращая внимания на их сжатие. Единственная проблема заключается в количестве фрагментов, что приводит к сбою дефрагментации, независимо от того, сжат ли фрагментированный файл или нет. Если количество фрагментов невелико (около 10000 уже в порядке), сжатый файл будет дефрагментирован и останется сжатым и неповрежденным.

4. Степень сжатия NTFS может быть хорошей, в зависимости от файлов. Системные изображения обычно сжимаются не более чем на 70% от их первоначального размера.

   Пара скриншотов для тех, кто не верит, но, конечно, вы можете сделать свои собственные тесты.

5. Я действительно делал реставрации из NTFS-сжатых образов, как фрагментированных, так и не фрагментированных, это работает, пожалуйста, либо доверяйте мне, либо просто проверьте это сами. rem: как я обнаружил около года назад, он не работает в Windows 8.1. Это работает в Windows 7, 8 и 10.

Ожидаемый ответ:

рабочий метод или программа для Windows:

1. сжать файл (с NTFS-сжатием и сохранить его доступным для восстановления Windows) без создания большого количества фрагментов (возможно, в другой раздел или создать сжатую копию; на жестком диске он должен быть как минимум в 3 раза быстрее, чем compact + defrag),

   или же

2. быстро (по крайней мере, в 3 раза быстрее, чем дефрагментация Windows на жестком диске) дефрагментировать разрушенно фрагментированный файл, например, содержащий более 100K фрагментов (он должен оставаться сжатым после дефрагментации).

Answer 1

Избегать фрагментации

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

Действительно, после сжатия уже существующего большого файла он будет ужасно фрагментирован из-за природы алгоритма сжатия на месте NTFS.

Вместо этого вы можете полностью избежать этого недостатка, заставляя ОС сжимать содержимое файла на лету перед записью его на диск. Таким образом, сжатые файлы будут записаны на диск как любые обычные файлы - без непреднамеренных пробелов. Для этого вам нужно создать сжатую папку. (Точно так же, как вы помечаете файлы для сжатия, вы можете пометить папки для сжатия.) После этого все файлы, записанные в эту папку, будут сжаты на лету (т.е. записаны в виде потоков сжатых блоков). Файлы, сжатые таким образом, могут все еще быть несколько фрагментированными, но это будет далеко от беспорядка, который создает сжатие NTFS на месте.

пример

NTFS сжал системный образ размером 232 Мбайт до 125 Мбайт:

• Сжатие на месте создало колоссальные 2680 фрагментов!
• Сжатие на лету создало 19 фрагментов.

дефрагментация

Это правда, что сжатые файлы NTFS могут создавать проблемы для некоторых инструментов дефрагментации. Например, инструмент, который я обычно использую, не может эффективно с ними работать - он замедляется до сканирования. Не беспокойтесь, старый верный Contig от Sysinternals выполняет работу по дефрагментации сжатых файлов NTFS быстро и без усилий!

Answer 2

Читая статью в Википедии о сжатии NTFS:

Файлы сжимаются в 16-кластерные блоки. С кластерами 4 КБ файлы сжимаются в блоки по 64 КБ. Если при сжатии данных уменьшается 64 КБ до 60 КБ или менее, NTFS обрабатывает ненужные страницы 4 КБ как пустые разреженные кластеры файлов - они не записываются.

Это обеспечивает разумное время произвольного доступа - ОС просто должна следовать цепочке фрагментов.

Однако большие сжимаемые файлы становятся сильно фрагментированными, так как каждый фрагмент <64 КБ становится фрагментом.

Обо всем по порядку. WBAdmin по сути является утилитой резервного копирования, которая может полностью восстановить систему. Таким образом, ожидается, что его выходной файл большой (> 4 Гб). Как видно из цитаты, большие файлы быстро фрагментируются. Это связано с тем, как NTFS сжимает: не по файлам, а по секторам.

Хорошей аналогией является разделение торта на несколько коробок, некоторые из которых не пустые. Это исходный файл. Компрессионная часть сжимает кусочки торта, оставляя пространство в коробках. Поскольку кусочки торта не вместе, из-за созданного пространства кусочки, которые составляют торт, становятся фрагментированными.

Я по-прежнему скептически отношусь к тому, что NTFS выдает такую степень сжатия. В соответствии с тестом, проведенным MaximumCompression для нескольких файлов, NTFS получает наименьшую оценку в степени сжатия - 40%. По личному опыту могу сказать, что он намного ниже, на самом деле настолько низок, что никогда не удосужился его использовать и не видел его эффектов.

Лучший способ избежать фрагментации - перестать полагаться на NTFS. Большинство дефрагментаторов не смогут развернуть или переместить сжатые файлы. Если бы они каким-то образом это сделали, NTFS не смогла бы расширить файлы, или, если бы он мог, так как процесс дефрагментации заполнил бы оставшееся пространство после сжатия (4 КБ), расширение могло бы фрагментировать файлы, поскольку файл не смог бы это сделать. быть записано в до смежных кластеров.

Это, как говорится, и если вам не нужно постоянно читать файл, используйте некоторые из форматов, рекомендованных в приведенной выше ссылке. 7z и rar довольно эффективны (то есть они сжимаются с высокими соотношениями в достойное время). Если вы заботитесь о пространстве, а не о времени, тогда выберите алгоритм типа PAQ (хотя вы будете тратить очень много времени на сжатие и распаковку файлов). Есть также быстрые алгоритмы.

Если вам нужно постоянно читать файл, не сжимайте его вообще. NTFS просто чертовски грязная.

Answer 3

Хотя это не совсем то, о чем спрашивал OP, у меня был хороший опыт работы со сторонним программным обеспечением под названием Paragon. NTFS по определению что-то ужасно ломает вашу файловую систему, когда вы сжимаете (а иногда даже пишете) файлы. Это распространяется на использование нескольких записей MFT, и ... Это плохо. Драйвер Microsoft NTFS даже не очищает это, когда файл подвергается дефрагментации. Следовательно, необходимы сторонние инструменты. Paragon позволяет вам загружать его как отдельную ОС (образ ISO) или устанавливать в другую ОС Windows с доступом к целевой файловой системе. Затем вы можете дефрагментировать как MFT, так и файлы. Насколько мне известно, это единственный способ исправить этот недостаток в NTFS, если не считать переформатирование тома.

(Я не имею никакого отношения к инструменту или его создателю, за исключением того, что это единственное, что я нашел на самом деле работает)

Сегодня, спустя 2 года после того, как вопрос был задан, я бы предпочел дедупликацию - это может сэкономить до 90% дискового пространства, если образы "немного" отличаются. Нано-сервер W2016 внутри виртуальной машины работает очень хорошо, но я подозреваю, что даже FreeNAS или что-либо еще, использующее ZFS, справится с этим.

Answer 4

В последнее время Windows рассматривает ZIP-файлы как папки. ZIP-файлы могут быть более сжаты, чем NTFS-сжатые файлы, и не являются фрагментированными по своей природе, в отличие от NTFS.

Почему бы не протестировать один из ваших образов дисков, сжимая их в 7-zip в формате ZIP, и посмотреть, можно ли его напрямую использовать для восстановления?

Если нет, поиграйте с параметрами сжатия 7-zip, чтобы максимизировать сжатие, используя лучший формат, например, 7z. Вы можете увеличить сжатие далеко за пределы NTFS и, следовательно, сделать намного больше места доступным на вашем диске - хотя быстрее всего будет распаковать его на второй физический диск или оперативную память, предпочтительно на другой контроллер и кабель ввода-вывода.

FWIW, сжатие окупается для SSD-дисков, не являющихся песочницами, для системных дисков и для файлов, не относящихся к мультимедиа - меньше износа SSD, больше места и более быстрый ввод / вывод для несжатых файлов. См. Http://www.tomshardware.com/reviews/ssd-ntfs-compression,3073-9.html.

Видео, графика и другие сжатые файлы данных (например,XLSX) уже очень сжаты, поэтому нет никакой пользы для сжатия NTFS. Ни для баз данных, ни для почты Outlook со случайными обновлениями. Но исполняемые файлы, txt, html и т.д. Файлы получают большую выгоду.

Сжатие также всегда выгодно для небольших файлов, например, если сжатие <64K, только один фрагмент. Только хлопот будет восстановление, если есть проблемы с диском.