Обновить

Одна команда в Windows 10/11 значительно экономит место на системном диске без снижения производительности

Время на прочтение2 мин
Охват и читатели111K
Всего голосов 44: ↑39 и ↓5+45
Комментарии109

Комментарии 109

Compact не только про ОС - см. Ключи запуска.

Можно прилично сжать Program Files, Program files (x86), другие папки.

Неплохо сожмется, если установлен Office или другое тяжелое ПО.

compact /c /s /a /i /exe:lzx "C:\*"

Обходимся этими тремя каталогами
compact /C /A /I /EXE:LZX /S:"C:\Program Files"
compact /C /A /I /EXE:LZX /S:"C:\Program Files (x86)"
compact /C /A /I /EXE:LZX /S:"C:\ProgramData"

А что по степени сжатия?

Зависит от развесистости установленного.

На системных дисках в 128Gb, на которых место выбрано почти в ноль, это даёт около 20Gb дискового пространства.

Вот "C:\Program Files (x86)" на моей машине:
14,098,121,418 total bytes of data are stored in 6,126,052,841 bytes.

The compression ratio is 2.3 to 1

На рабочем SSD 256 который почти закончился освободилось примерно 38, так что да где-то 15% высвобождается

Эти 20 гигов моментально испарятся при создании свежего файла гибернации или кеша браузера

А зачем создавать новые? Они уже созданы.

гибернацию можно отключить. Например, для винды в виртуалке он лишний.

C:\Program Files: Сжато файлов: 315960, в каталогах: 48540 Данные объемом 81 034 707 783 байт сохранены в 34 663 669 437 байт. Степень сжатия 2,3 к 1.

C:\Program Files (x86): Сжато файлов: 59028, в каталогах: 17565 Данные объемом 17 438 599 320 байт сохранены в 6 204 368 513 байт. Степень сжатия 2,8 к 1.

C:\ProgramData: Сжато файлов: 33297, в каталогах: 4716 Данные объемом 22 589 809 099 байт сохранены в 18 673 626 251 байт. Степень сжатия 1,2 к 1.

compact /compactos:always Завершено сжатие двоичных файлов ОС.

Сжато файлов: 87194, в каталогах: 100745 Данные объемом 17 103 117 459 байт сохранены в 9 663 386 446 байт. Степень сжатия 1,8 к 1.

R5 5600 / ssd m2 / время заняло 4 игры в Пасьянс Паук..

Он ещё игры отлично сжимает

lzx сильно процессор грузит по сравнению с xpress16k, по сжатию разница минимальная

compact /c /s /a /i /exe:xpress16k "C:\Program Files"

Он ещё игры отлично сжимает

После чего в играх перестаёт работать DirectStorage.

перестаёт работать DirectStorage

Лично не сталкивался. Разжать также одной командой проблем нет.

Разжать можно, да. Но надо об этом помнить. Сама суть DirectStorage такова, что текстуры с nvme ssd идут по pcie прямо в видеокарту, минуя процессор.

надо, чтобы теперь бычки-производители видеокарт добавили поддержку этого компакта

насчёт сильно грузит процессор: i7-11700К, compact /C /A /I /EXE:LZX /S:"C:\ProgramData" максимальная загрузка по всем ядрам - 48%, в среднем где-то 25%. это сильно? 🤔

Сжато файлов: 15777, в каталогах: 3720 Данные объемом 29 536 807 288 байт сохранены в 22 117 169 117 байт. Степень сжатия 1,3 к 1.

собсно, до этой команды было 59 ГБ свободно, сейчас 66 ГБ 🤔 Это только ProgramData была обработана

В среднем - ну такое себе определение. Что запущено-то? Может быть, у вас какой-то процесс жрет проц, а не расжатие.

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

Сжимать C:\ProgramData с ключом /EXE:LZX - странное решение. Этот ключ предназначен для сжатия файла целиком, без возможности автоматического пережатия при изменении. При первой же записи весь файл целиком вернётся в несжатое состояние. Достаточно сжать программные файлы, они изменяются редко, хотя после массового обновления софта их снова придётся пережимать.

Интересно - действительно я совершенно неправильно понял процесс.

В работе мы использовали вариант без /exe, но вариант @palienмне понравился больше, и я добавил ключ.

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

Однако использование двух последовательных команд:

compact /C /A /I /EXE:LZX /S:"C:\Program Files (x86)"
compact /C /A /I /S:“C:\Program Files (x86)”

приводит к сохранению компрессии LZX и включению традиционной компрессии NTFS с наследованием.

Давайте заодно всё же измерим степени сжатия:

C:\Program Files (x86) - Size 16,4 GB (17 700 827 755 bytes)
Разжимаем
compact /u /A /I /S:“C:\Program Files (x86)”

compact /u /EXE /A /I /S:“C:\Program Files (x86)”
Size on Disk 16,5 GB (17 801 523 200 bytes)

compact /C /A /I /S:“C:\Program Files (x86)”

Size on Disk: 11,6 GB (12 558 749 696 bytes)

compact /C /A /I /EXE:xpress16k /S:"C:\Program Files (x86)"

Size on Disk 8,50 GB (9 137 377 280 bytes)

compact /C /A /I /EXE:LZX /S:"C:\Program Files (x86)"

Size on Disk 7,20 GB (7 738 306 560 bytes)

В итоге, как лучше с /EXE:LZX или без запускать, чтобы оптимально было по быстродействию и без лишней перезаписи ssd?

Эксперименты показали что самый деловой вариант - два прохода:
compact /C /A /I /EXE:LZX /S:"C:\Program Files (x86)"
compact /C /A /I /EXE:LZX /S:"C:\Program Files"

compact /C /A /I /S:“C:\Program Files (x86)”
compact /C /A /I /S:"C:\Program Files"
compact /C /A /I /S:"C:\ProgramData"

приводит к сохранению компрессии LZX и включению традиционной компрессии NTFS с наследованием.

Это два принципиально разных подхода к сжатию. Традиционная компрессия берёт дефолтный (безымянный) поток файла, делит его на куски по 16 кластеров, сжимает и пишет обратно. Такой подход обеспечивает возможность пересжатия изменяемых участков файла. Цена такого сжатия - чудовищная фрагментация.

Компрессия с флагом /EXE сжимает файл целиком, порождает именованный альтернативный поток FileName:WofCompressedData, записывает сжатый файл туда, а дефолтный поток уничтожает. При перезаписи файла (фрагмента файла) происходит полная распаковка файла, запись распакованного варианта в дефолтный поток, именованный поток уничтожается.

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

А Клод ничего похожего не предложил, когда маме нужно было ноут почистить, ручками удалял апдейты и кеши инсталлера + cleanmgr + " Dism /Online /Cleanup-Image /StartComponentCleanup /ResetBase"

Как говорил классик, "Малыш, ну я ведь лучше собаки!"

ОС Windows начинает хранить системные файлы в сжатом виде, а не в несжатом виде на диске

Надмозг + отсутствие вычитки))

Три раза прочитал это и мозг просто выкинул эксепшн

Экстремальное сжатие до 0 гигабайт :)

format c:

причем эта команда существовала еще в ms-dos, а потом перекочевала в windows.

Странно, что столько плюсов вашему комментарию

Странно, что столько плюсов вашему комментарию

Потому что это популярный мем в *nix сообществе. А три плюса это много? Дефляция плюсов на хабре, не иначе.

А три плюса это много?

Три плюса — это [!]!

2:5015/519 на связи :)

В вин9х, помнится, вот такое проходило:
echo y|format c:

зашёл только в поисках этого комментария :)

Не нарастит место на диске Ц, но тоже полезная команда:

chmod -R 0000 /

"Месье знает толк в извращениях"

cat /dev/null | tee \.\Volume-чего-то-там… Раньше поисковики сразу давали ссылку на мсдн, а сейчас несут бред, все эти копилоты, Алисы и прочие гугли и мсдн в выдаче нет. Каг таг? Или сейчас программисты пишут по выдаче поисковиков, а там статья типа этой, Пикабу или другой отсюда, где нтфс появилась в хп…

где нтфс появилась в хп

Как бы NTFS v3.1 появилась в 2001-м вместе с XP. https://en.wikipedia.org/wiki/NTFS#Versions

А версия 3.0 и раньше? Не существовало? А на чем работала windows nt3.1…nt5.0? К слову, хрюша это нт 5.1

А я на что ссылку дал?

Там как раз инфа про все версии NTFS, начиная с первой, которая с WinNT 3.1 появилась. Просто теми системами (может кроме 2000) сравнительно мало кто пользовался и предшественником ХРюши скорее была 98-я у подавляющего числа юзверей, кмк.

Туше! Я говорил о статье, где зумер с апломбом вещал что нтфс появилась в хп. Статья про то как без пайки из 250гб ссд сделать 320 :) Пошёл, немного похмыкал. Вот и упомянул о таком факте.

значит просто нужно было более развёрнуто выразить свою мысль

Попробовал. До: 46,8 GB, после: 32,8 GB

98946 files within 146423 directories were compressed.
23 227 550 164 total bytes of data are stored in 13 296 948 629 bytes.
The compression ratio is 1,7 to 1.

Время не засекал, но процесс небыстрый

PS: размер указан для папки с:\windows

Учти что любой патч или обновление драйверов распакует измененные файлы обратно до нормального размера

PS C:\Windows\system32> compact /compactos:query

Система не находится в состоянии сжатия, так как, по данным Windows, это состояние не является полезным для системы.

Сжатие Program Files не оказывает негативное влияние.

Свободно 500 гиг на террабайтном SSD - какой смысл сжатием заниматься?

Какой смысл задавать бессмысленные вопросы?

Да

Любое сжатие оказывает некое влияние, т.к. расходуются, пусть и незначительные, ресурсы на распаковку сжатого.

Если на системном разделе хватает свободного места, нет смысла этим заниматься.

Да, но в условиях дефицита памяти, можно пожертвовать тем, что в избытке. Кто пару лет назад знал, что так обернется.

Неужели программисты начнут писать эффективные программы, а hello_world.exe не будет занимать 12mb на диске?

Место на диске под программы все равно стоит пренебрежимо мало. Нет смысла.

Неужели программисты начнут писать эффективные программы, а hello_world.exe не будет занимать 12mb на диске?

Нет.

В звукозаписи есть такая процедура, как shit-control. Она заключается в прослушивании и, если необходимо, последующей коррекции материала на низкокачественном оборудовании, чтобы оценить, как это будет звучать у "обычного слушателя" на бумбоксе или новомодной портативной колонке, а не у энтузиаста Hi-Fi в шумоизолированной комнате на небюджетных Dynaudio или PSB. В разработке ПО такого нет, и разработчики ПО, кажется, совершенно искренне уверены, что их старые (прошлого года) едва ворочающиеся рабочие станции на не-топовых i9 14500KS со взятыми до подорожания всего лишь 64GB памяти - это ниже начального уровня, и у пользователей их ПО, без сомнений, компьютеры в среднем куда как быстрее и памяти имеют куда как больше, а значит экономия ресурсов бессмыслена.

Хотел поставить вам плюсик, большой, а кармы нет ). Программерам точно нужно вводить такой шитконтроль!

давно такое предлагаю. это надо падаван с младых ногтей прививать, давать им самые слабые машины. проблемма только в том что и IDE на них еле ворочается, для обычного stm32 код компилируется нереально долго на делеко не самой старой машине и хочется какой нить ryzen, че нибуть с 12-24-128 ядрами. и компилятор то ведь работает, реально оптимизирует этот код на десятки килобайт

Неужели программисты начнут писать эффективные программы, а hello_world.exe не будет занимать 12mb на диске?

Да фиг с ним с exe'шником то. Другая беда пострашнее: засирание AppData.

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

Ну и вишенка на торте - в деинсталяторе забывает про это все. Программу то удалили, а вот гигабайты мусора остались.

Добавлю, что ровно то же самое происходит в Андроиде, с той только разницей, что пишется весь этот шлак в защищённый раздел, куда без root доступа нет. А потом на карте накопителя 80% занимают "другие файлы". И ни один разработчик, в т.ч. Гугл, не заботится о какой-либо оптимизации. Закончилось место — купите новый телефон, что вы как маленький!

Закончилось место — купите новый телефон

Есть же сброс до заводских: так может удалиться и некоторый софт, который имелся на свежекупленом смарте, который ты только что распаковал. Ну и чистилки типа Maid SD есть. Хотя без рута они тоже не всё осилят почистить. Особенно на ведроидах 10+.

Как будто на iOS то же самое. Знаменитый раздел "Системные данные" с кучей непонятного мусора, который чистится только полным сбросом телефона (есть странные способы с переводом времени но мне не помогают), что в условиях выпиливания некоторых программ из AppStore превращается в проблему.

У меня у самого он занимает почти 30ГБ на 128ГБ телефоне и удаление программ по одной его никак не чистят – только форматирование.

Видел скриншоты с ~300ГБ системных данных на 1ТБ айфоне.

это определяется по типу накопителя - скорее всего у Вас SSD, и, по мнению системы, сжатие не повлияет на время чтения, а в следствии на скорость загрузки/работы системы.

Однако. А у нас на обоих доступных ноутах (винда 10), при этом первый раз про эту команду слышим.

Когда утилита compact.exe /exe:lzx сжимает файл, драйвер Wof.sys выполняет перестройку его структуры:

  1. Файл превращается в Sparse (разреженный): NTFS очищает физические сектора основного тела файла. С точки зрения диска, основной поток данных файла теперь занимает 0 байт.

  2. Размер файла сохраняется: В метаданных NTFS («логический размер») по-прежнему записан оригинальный, несжатый размер файла. Это нужно, чтобы любые сторонние программы (проводник, игры, редакторы) думали, что читают обычный файл.

  3. Создается Alternate Data Stream (ADS): Все сжатые данные (неважно — LZX или XPRESS) записываются в именованный альтернативный поток данных, который называется :WofCompressedData.

  4. Устанавливается Reparse Point (точка повторной обработки): На файл вешается специальная метка IO_REPARSE_TAG_WOF. Она сигнализирует файловой системе: «Каждый раз, когда кто-то пытается открыть этот файл, позови драйвер Wof.sys».

    Когда Wof.sys выполняет распаковку «на лету» при записи, файл создается заново из фрагментов в тех местах диска, где прямо сейчас есть свободные сектора. Если диск сильно заполнен, файл станет критически фрагментированным, что приведет к сильному падению скорости чтения этого файла в будущем.

    Не рекомендуется (высокий риск): Для активно перезаписываемых файлов (базы данных SQL, файлы виртуальных машин .vhdx, постоянно обновляемые логи, рабочие документы). Постоянный цикл «сжал утилитой — программа записала — файл аварийно распаковался» рано или поздно приведет к ошибкам логики приложений из-за нехватки места или таймаутов ввода-вывода.

Пункт 4 означает, что каждое чтение файла будет приводить к записи на SSD? Или я что-то не так понял?

нет, это говорит о том, что файл надо читать не "напрямую", а через вызов wof.sys

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

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

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

Не думал, что фрагментация влияет на скорость чтения в SSD.

Stacker портировали в винду? ;)

Эта опция была ещё в Windows XP и называлась "Сжимать содержимое для экономии места на диске ", т.е. можно было сжать весь диск C:\ или любой другой диск. В те времени жёсткие диски были по 40 GB и 80 GB, поэтому эта опция пользовалась популярностью.

Сейчас в Windows 10 и 11 есть утилита - CompactOS:

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

  • Применяется к файлам операционной системы.

  • Использует другой алгоритм сжатия (XPRESS4K) и позволяет выбрать другой алгоритм для исполняемых файлов.

Почитать про всё это можно по ссылке - https://remontka.pro/compress-drive-save-space-windows/

Так что по факту всё новое - это хорошо забытое старое.

Эта опция была еще в MS-DOS: DriveSpace/DoubleSpace.

Еще раньше был stacker )

вы путаете, это другой способ.

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

Случиться что-то страшное, когда все узнают про dism

А как оно сжатое будет из того же lunux читаться, если ntfs примонтировать?

Нормально читалось даже много лет назад.

Подождите! А что можно сделать в Windows 7? Место осталось мало, а удалять уже нечего.

Это не то! Вопрос в том, чтобы почистить, например, AppData от ненужных уже гигабайтов. Да и в system32 тоже много всякого мусора. А внятного механизма очистки нет. Кажется, освобождаешь место, а оно опять куда-то девается! Вирусы? Майнеры? Копилоты? А ещё файл подкачки.

Есть же чистилки (типа CCleaner) для винды и всякие оптимизаторы.

Ну а средствами самой винды не помню есть ли способ очистки от мусора.

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

Ну и для того чтобы посмотреть какие папки сколько места занимают я использую уже довольно давно утилиту Scanner. Взять можно у автора: http://www.steffengerlach.de/freeware/

Сжимать неудаляемый мусор внутри Windows, чтобы сэкономить место - это как трамбовать ногами переполненное мусорное ведро вместо того, чтобы просто его вынести.

У меня emerge --depclean просто берёт и физически удаляет всё лишнее под корень

Знаете, чем линуксоиды похожи на вегетарианцев?

Чем же?

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

Мда, когда используешь эту утилиту лет 15. Что дальше, презентация makecab.exe на хабре? Или скрипта на VBS для встроенного ZIP?

Только проблема, что когда нет места на винду, еще обычно и памяти нет, и процессор от калькулятора...

LZX - сжатия раньше не было, оно на максималках сродни 7zip, к тому же оптимально для кеша современных процессоров.

Зумеры переизобрели doublespace, который был еще в dos.

Когда много программ установлено, можно больше сэкономить сжав папку и глюков нет.

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

вы почитайте ещё, это не NTFS-сжатие

Что будет если такие сжатые файлы открывать из под Ubuntu / MacOS / Android, думаю для старых Windows вопрос также актуален, особенно старых? Они не откроют файл, испортят его, напишут, что ФС повреждена?

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

упаковщики применялись еще на zx spectrum/c64/etc для экономии ресурсов и только гораздо позже это стало вдруг внезапно требовать ресурсы. MS прекрасно могли внедрить это на уровне стандарта просто ужимая все exe/dll файлы сразу на этапе компиляции в VS/SDK. Но сделали более универсальный, низкоуровневый и более сложный костыль, отключенный однако по умолчанию - интересно почему бы..

Я помню, мы так Turbo Pascal умещали на одной дискете на 1.44Мб

А если дискета сопротивлялась - то ее делали на 1.8 Мб )

(жаль тогда до черепичной записи еще не дошли..)

На SSD такое уже не прокатит...

Черепичная запись на SSD?
Уже давно прокатывает, используется ее аналог QLC :)

Тебя я сразу пэкалайтом запакую
Чтоб ты на диске меньше места занимал
И турболинк с тобою рядом помещу я
Чтоб он твои обж файлы линковал..

Из песни "Бухгалтер Ассемблер, милый мой ассемблер"

Так это вроде бы всем известная командна, в чём новость? :)

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

Если что-то упадёт, файлы восстановятся? Похожее сжатие было ещё Win9x. Сначала всё вроде хорошо, но потом начинаются проблемы.

Я бы ускорял ОС, а не тормозил. Windows и так с каждым годом всё медленней.

Вот бы ещё команду, чтобы диск не съедался сам собой. А то ничего не устанавливаешь, а свободное пространство постепенно сжимается.

Обычно ставлю систему через WinNTSetup, поэтому думал, что XPRESS4K сейчас у всех)

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации