Как расширить память SSD с 256 до 320 ГБ без паяльника и лишних усилий

В условиях текущего подорожания оперативной памяти и флеш-накопителей, затронувшего весь рынок потребительской электроники, регулярная модернизация ПК или замена накопителя на более емкий стала для многих ощутимой статьей расходов. Твердотельные накопители объемом 256 ГБ по-прежнему остаются наиболее доступными, однако их практическая ценность стремительно падает: ресурсоемкое современное ПО и тяжелые игры способны исчерпать этот объем практически мгновенно. При этом долговременное заполнение SSD более чем на 90% чревато резким ускорением деградации ячеек памяти из-за эффекта усиления записи. Постоянная перезапись на минимальном оставшемся пространстве быстро выводит блоки из строя, приводя к преждевременной гибели накопителя.

Истоки проблемы и пути решения

В эпоху зарождения игровой индустрии разработчики были вынуждены филигранно экономить каждый байт: объем типичного картриджа составлял от 1 до 4 мегабит (всего 128–512 КБ). Сегодня же приложения и игры, нередко создаваемые с активным привлечением генеративного ИИ, весят десятки гигабайт и требуют внушительных вычислительных мощностей, нередко демонстрируя при этом худшую отзывчивость, чем софт тридцатилетней давности на ретро-железе.

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

«Самое примечательное достижение индустрии программного обеспечения состоит в том, что она методично сводит на нет все поразительные успехи разработчиков аппаратного обеспечения» — Генри Петроски

Необходимость в сжатии данных возникла еще в 1990-х: компрессии подвергались исходный код, спрайты, текстуры и кат-сцены. Настоящим эталоном мастерства стала компания Capcom. В 1996 году для порта Street Fighter Alpha 2 на Super Famicom был разработан специальный вспомогательный чип динамической декомпрессии, позволивший уместить 224-мегабитную аркадную версию CPS-II на 32-мегабитный картридж SNES. Двумя годами позже команда Angel Studios совместно с Capcom совершила технологический прорыв, сжав Resident Evil 2 с двух дисков объемом 650 МБ до одного 64-мегабайтного картриджа для Nintendo 64.

Сегодня при загрузке дистрибутива в формате .exe, .msi или архива размером около 100 МБ после завершения инсталляции программа нередко разворачивается в 300–400 МБ несжатых данных. Логичный вопрос — можно ли сохранить компактность установленного приложения без потери функциональности? Единственным барьером здесь остается неосведомленность пользователей о возможностях прозрачной файловой компрессии.

Как развивались встроенные механизмы сжатия

Немного исторического контекста.

С выходом Windows XP стандартной стала файловая система NTFS. Одной из ее ключевых особенностей, актуальных и спустя четверть века, является прозрачное сжатие данных на системном уровне. Механизм прост: файл разбивается на 64-килобайтные блоки, каждый из которых независимо сжимается алгоритмом LZNT1. Драйвер NTFS на лету производит декомпрессию при чтении и компрессию при записи. Для пользовательского софта процесс абсолютно прозрачен: дисковое пространство освобождается без нарушения целостности файлов.

В свойствах любого логического тома в Проводнике Windows присутствует опция «Сжимать этот диск для экономии места», использующая все тот же LZNT1. Примечательно, что данный механизм без изменений перекочевал из Windows XP прямо в Windows 11.

Однако активировать этот системный флаг категорически не рекомендуется. Реализация Microsoft тридцатилетней давности лишена избирательности и пытается уплотнять абсолютно все файлы подряд. Устаревший алгоритм LZNT1 создает неоправданную нагрузку на центральный процессор, замедляя отзывчивость ОС. Для классических HDD тотальное сжатие гарантирует катастрофическую фрагментацию, а для современных SSD означает резкий рост паразитных циклов перезаписи и быстрый износ флеш-памяти.

В экосистеме Apple аналогичная технология прозрачной компрессии для файловой системы HFS+ появилась в Mac OS X 10.6 Snow Leopard на базе фреймворка decmpfs. С переходом на APFS в macOS High Sierra функционал был сохранен. В отличие от блочной архитектуры NTFS, реализация Apple работает на уровне метаданных конкретных файлов, исключая фрагментированное чередование сжатых и несжатых участков в пределах одного дескриптора.

В среде Linux аналогичные возможности заложены в архитектуру файловых систем нового поколения: btrfs и ZFS поддерживают современные алгоритмы lz4, zstd и gzip. Прозрачное сжатие можно включить как глобально для раздела, так и точечно для директорий. Нередко это даже повышает общую производительность дисковой подсистемы за счет снижения физического объема операций ввода-вывода. Для взаимодействия со сжатыми разделами NTFS в ядро Linux интегрирован драйвер ntfs3.

Современный инструментарий

Наиболее эффективные решения сегодня предлагает сообщество разработчиков открытого ПО:

Для платформы macOS отличным выбором является applesauce.

Утилита позволяет сжимать, восстанавливать и анализировать данные на томах HFS+ и APFS, поддерживая нативные алгоритмы Apple: LZFSE (оптимизированный под архитектуру Apple Silicon), LZVN и ZLIB. В отличие от устаревшего инструмента afsctool, applesauce распараллеливает обработку данных даже в пределах одного файла, бережно расходует оперативную память, корректно отображает статус выполнения и обеспечивает безопасность записи за счет атомарного переименования временных файлов. Управление осуществляется через терминал: applesauce compress -c LZFSE <путь_к_папке>.

В мире Linux для пользователей btrfs удобным решением выступает Btrfs Assistant. Впрочем, чаще параметры компрессии задаются напрямую через опции монтирования (например, compress=zstd:1 в /etc/fstab) либо через атрибуты папок (btrfs property set / chattr +c). Для уже записанных массивов применяется дефрагментация со сжатием: btrfs filesystem defrag -czstd -rv <путь>, а реальный коэффициент оценивается утилитой compsize.

Однако наиболее гибкая экосистема утилит для конечного пользователя сформировалась вокруг Windows.

Начиная с Windows 10, в ОС появилась консольная утилита compact.exe с расширенным набором современных алгоритмов, что послужило толчком к созданию графических оболочек:

• trash-compactor (актуальный проект с интеллектуальным анализом — подробнее ниже);

• CompactGUI;

• compactor (проект на Rust, развитие приостановлено).

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

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

• Облачная база коэффициентов сжатия для популярных тайтлов из Steam и EGS. Если же директория содержит сторонний софт или некаталогизированную игру, прогноз недоступен, и обработка выполняется вслепую, что делает одновременное пакетное сжатие разнородных данных неэффективным.

• Фоновая служба Background Watcher, отслеживающая обновления игр и автоматически восстанавливающая сжатие при простое ПК.

• Пользовательские списки расширений-исключений.

Стоит помнить: CompactGUI не рекомендует применять сжатие к проектам, использующим API DirectStorage, чтобы не свести на нет преимущества прямой потоковой загрузки текстур в видеопамять.

Утилита Compactor, созданная на базе Rust, долгое время превосходила аналоги по скорости работы. Она умеет пропускать уже сжатые структуры, экономно использует ОЗУ и хранит локальный хеш-кеш несжимаемых файлов для ускорения повторных проходов.

Тем не менее оба решения обладают схожими концептуальными ограничениями:

• Отсутствие глубокого предиктивного анализа сжимаемости данных «на лету» для файлов с динамически меняющимся содержимым (что критично для кэшей приложений на базе Electron объемом в несколько гигабайт).

• Необходимость применения одного фиксированного алгоритма ко всему каталогу без учета размера конкретных файлов и вычислительного потенциала ЦП. Алгоритм LZX эффективен далеко не везде.

• Отсутствие полностью автоматизированного сценария работы в один клик.

• Сложность подбора оптимального профиля сжатия для неподготовленного пользователя: от ручного выбора между XPRESS4K и ресурсоемким LZX зависит не только размер, но и общая скорость отклика системы.

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

Практическая реализация: trash-compactor

Проект trash-compactor (основная ссылка на релизы, а также зеркало проекта) поддерживает два сценария взаимодействия:

1. Интуитивный графический интерфейс для персонального использования.

2. Полнофункциональный консольный интерфейс (CLI) для интеграции в задачи Планировщика Windows и скрипты централизованного администрирования парка ПК.

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

В GUI-режиме доступны два сценария:

1. Быстрая компрессия стандартных каталогов (Program Files, AppData, Downloads) и интеграция с системным механизмом CompactOS, позволяющим высвободить порядка 30–40% дискового пространства папки Windows.

2. Выборочное сжатие пользовательских папок на любых накопителях, отформатированных в NTFS.

Процедура абсолютно безопасна: файлы не модифицируются на логическом уровне и не повреждаются. При обычном копировании на внешний накопитель (например, флешку с exFAT) данные автоматически разворачиваются в исходный вид, что позволяет эффективно хранить на накопителе объемом 256 ГБ массив данных, эквивалентный 320 ГБ и более.

К категории плохо поддающихся сжатию типов файлов относятся:

• Мультимедийные форматы и архивы, уже использующие встроенную компрессию (видео, аудио, JPEG/PNG, ZIP/RAR/7z);

• Офисные документы формата OpenXML (docx, xlsx, pptx), файлы pdf и их производные;

• Весовые коэффициенты моделей машинного обучения (gguf, safetensors, torch);

• Виртуальные диски и образы виртуальных машин (декомпрессируются при первой записи);

• Кастомные игровые архивы и контейнеры предсжатых ресурсов.

Для высокоточного определения таких структур trash-compactor использует гибридный сканер. На первом этапе анализируются расширения, а для неизвестных форматов применяется расчет информационной энтропии Шеннона: утилита считывает и тестирует быстрым алгоритмом случайные 16-килобайтные фрагменты файлов исключительно в оперативной памяти без лишних циклов записи на SSD. Если потенциал сжатия подтверждается, к файлу применяется наилучший алгоритм.

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

trash-compactor воплощает концепцию «умного расширения емкости диска» без скрытых платежей и сомнительных твиков, а исходный код проекта открыт для аудита.

Технические подробности реализации

Быстрый обход и классификацию файлового дерева обеспечивает модуль fast_walk, написанный на Rust с применением крейтов PyO3 и rayon. Скомпилированный бинарный модуль упакован внутри wheel-пакета приложения. Параллельный сканер фильтрует файлы по сигнатурам и маскам, определяет оптимальный алгоритм с учетом размера и запрашивает флаги через Win32 API GetFileAttributes, чтобы исключить повторную обработку сжатых структур.

В ходе первичного анализа из каждой директории отбирается репрезентативная выборка (~50 файлов), где считываются плавающие окна по 16 КБ с отступом от заголовков и служебных структур, снижая вероятность ложных срабатываний. Экспресс-оценка проводится сверхбыстрым алгоритмом LZ4; при наличии сжатия блок повторно прогоняется через ZLIB уровня 2. Если средний коэффициент сжатия каталога оказывается ниже 15% (порог настраивается), вся ветка отсекается, а ее хеш по алгоритму xxhash64 заносится в базу incompressible.db.

Этот метод с надежностью свыше 95% отсекает массивные каталоги с кэшами приложений на платформе Electron (Discord, Telegram, Slack, VSCode, Spotify, Notion, Obsidian, Figma, Teams, Postman и др.), предотвращая бессмысленный нагрев процессора и перезапись динамических данных.

При выполнении компрессии утилита динамически распределяет нативные алгоритмы Windows 10/11:

• XPRESS4K (минимальная нагрузка на CPU);

• XPRESS8K;

• XPRESS16K;

• LZX (максимальная степень сжатия).

  Сетка распределения: файлы до 64 КБ сжимаются через XPRESS4K, до 256 КБ — XPRESS8K, до 1 МБ — XPRESS16K, свыше 1 МБ — через LZX (при достаточном запасе производительности процессора).

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

Поскольку LZX чувствителен к однопоточной мощности, программа выполняет калибровочный тест декомпрессии на старте. Если тестовый блок не укладывается в норматив 0.25 секунды, использование LZX блокируется, а сжатие переводится на щадящие профили XPRESS, гарантируя стабильную отзывчивость системы на любых конфигурациях.

 

Источник