В текущих реалиях кризиса ОЗУ и флеш‑накопителей, затронувшего всю электронику, многие пользователи компьютеров и ноутбуков не могут позволить себе покупку новой электроники или даже апгрейд SSD. SSD на 256ГБ остаются в пределах досягаемости по цене из‑за их распространённости, но ими уже почти никто не хочет пользоваться, потому что современные программы и игры стали занимать ну очень много места на диске, и 256-гигабайтные SSD очень легко забить. А как известно, выше 90% ёмкости у SSD занимать в долгосрочной перспективе крайне не рекомендуется из‑за сильного и быстрого износа блоков памяти, который будет происходить в будущем — эффект будет как от иглы, которая проделает дыру, протыкая очень маленькую площадь. Так же будет и с SSD, в котором быстро образуется дыра в лице убитых блоков памяти, и он станет непригодным к использованию, если его забить донельзя.
Что можно сделать
Раньше, программистам приходилось умещать программы в очень небольшие пространства на дисках и в ОЗУ. Среднестатистический картридж у игровых приставок содержал от 1 до 4 мегабит данных, или от 128КБ до 512КБ. Сейчас же современные программы и игры (теперь нередко состряпанные с помощью ИИ) занимают гигабайты памяти и требуют огромных мощностей от железа, при этом работают они значительно медленнее, чем старые программы на старом железе.
Всё, что поменялось — делать такие программы теперь можно чуть быстрее и можно нанимать менее компетентных программистов. А все минусы, типа неоптимизированных алгоритмов, кучи ненужных зависимостей и упущений программистов, покроет пользователь — он оплатит покупку дорогого и мощного компьютера, который это всё вытянет.
«Самое удивительное достижение индустрии программного обеспечения — в том, что она постоянно нивелирует ошеломляющие успехи производителей аппаратного обеспечения» — Генри Петроски
Но уже в 90-х годах программистам пришлось научиться сжимать данные на дисках — у тех же игр приходилось сжимать код, текстуры, анимации, а затем и видеоролики. Capcom лидировала в этой сфере — в 1996 году они выпустили Street Fighter Alpha 2 для Super Famicom, использующую чип для распаковки сильно сжатых данных налету, чтобы уместить игру, занимавшую 224 мегабита на аркадном железе CPS‑II, на 32-мегабитном картридже SNES. А в 1998 вместе с Angel Studios, Capcom выпустила порт Resident Evil 2 на Nintendo 64, где диск с 650МБ данных удалось сжать до 64МБ.
Когда вы скачиваете любую программу из интернета, она предоставляется в файле.exe,.msi,.zip (с последующей распаковкой) и в других форматах — но после установки, программа превращается из 100МБ в 300–400МБ. А разве нельзя сделать так, чтобы 100МБ были близки к 100МБ? Что мешает этому? На самом деле, мешает только незнание того, что эти данные программ можно сжать. А как их сжимать?
Как это делалось
Минутка истории.
В Windows XP появилась файловая система NTFS. Из множества плюсов NTFS, которая во всю используется по сей день (а прошло уже 25 лет), выделяется возможность сжатия файлов на уровне файловой системы. Это работает так: данные в файле делятся на блоки по 64 КБ. Каждый такой блок сжимается независимо алгоритмом LZNT1 и помечается, как сжатый. При чтении драйвер NTFS автоматически распаковывает нужные блоки на лету, а при записи — сжимает заново. Для приложений этот процесс невидим, но фактический объём занимаемого программами места на диске становится меньше — а сам процесс не приводит к потере информации.
Когда вы открываете свойства диска в Проводнике, вам даётся возможность сжимать диск для экономии места. Именно здесь и используется алгоритм LZNT1 для сжатия данных. Причём этот алгоритм использовался от Windows XP и используется по сей день даже в самых новых версиях Windows 11.
Но нажимать на этот флаг не надо. Как всегда, программисты Microsoft внедрили полу‑меры, но до ума эту технологию не довели, чтобы сжимать данные по‑умному, а не всё, что попало. LZNT1 — слабый и устаревший алгоритм по сегодняшним меркам, а из‑за сжатия всего подряд, у вас без причин увеличится нагрузка на процессор и замедлится система. А если у вас по сей день используется жёсткий диск вместо SSD, то фрагментации диска не миновать. Для SSD же это безпорядочное и постоянное сжатие означает дополнительный износ ячеек памяти.
В macOS идентичное прозрачное сжатие файлов на уровне файловой системы HFS+ (впервые появилась в macOS 8.1) добавили в версии OS X 10.6 Snow Leopard через механизм decmpfs. Позже, в macOS 10.13 High Sierra, на смену пришла APFS (Apple File System), которая унаследовала и продолжает поддерживать то же сжатие. В отличие от NTFS, где сжатие глубоко интегрировано в структуру кластеров файла и может смешивать сжатые и несжатые куски внутри одного файла, у Apple сжатие ориентировано не на блоки, а на файлы, через метаданные.
В Linux похожий функционал есть в современных файловых системах. btrfs и ZFS поддерживают прозрачное сжатие алгоритмами lz4, zstd, gzip и др. Его можно включить для всего раздела или избирательно, и иногда это даже ускоряет работу, потому что уменьшается объём чтения/записи с диска. Для работы с уже сжатыми NTFS‑томами из‑под Linux есть поддержка в драйверах ntfs3.
Как это делается теперь
Спасение идёт от сторонних утилит от энтузиастов с открытым исходным кодом:
Для macOS — applesauce.
Она умеет сжимать, разжимать и показывать информацию о файлах на HFS+ и APFS. Поддерживает три алгоритма Apple: LZFSE (он специально для процессоров M‑серии, тоесть Apple Silicon), LZVN и ZLIB. Раньше использовался afsctool, но в отличии от него, эта утилита параллелит процесс сжатия даже внутри одного файла, меньше жрёт памяти, показывает нормальный прогресс и безопасно пишет через временный файл с атомарным переименованием. Интерфейса с кнопками нет, делается всё через терминал: applesauce compress -c LZFSE <директория>.
Для Linux, самое близкое — это Btrfs Assistant для файловых систем btrfs, потому что в Linux сжатие живёт глубже — внутри самих файловых систем. В btrfs и ZFS его включают при монтировании опцией compress=zstd:1 в fstab или mount, или выборочно для конкретных файлов и папок командами chattr +c и btrfs property set. Для уже записанных данных запускают дефраг с флагом сжатия: btrfs filesystem defrag -czstd -rv <путь>. Посмотреть реальную экономию пространства на диске помогает утилита compsize.
Btrfs Assistant косвенно помогает, но само сжатие чаще настраивают через терминал или при установке системы. Выборочное сжатие отдельных директорий, отдельных игр, с умным выбором алгоритма — даже если осуществимо, то только через скрипты.
А для ОС Windows, которые в этой сфере лидируют, всё проще для обычного пользователя.
В Windows 10 добавили утилиту compact.exe, с которой стало возможно сжатие индивидуальных файлов, Это привело к созданию энтузиастами таких программ:
trash‑compactor (самая актуальная, созданная мной — о ней чуть позже)
compactor (устарела)
Самая известная, однако не самая лучшая — CompactGUI. Эта программа идёт с упором на сжатие видеоигр, скачанных из Steam, но для остального она подходит не очень хорошо. Принцип работы — выбираешь папку, один из четырёх алгоритмов, смотришь прогноз сжатия (если для какой‑то игры есть такая информация), и если всё устраивает — то делаешь сжатие.
В бета‑версии 4.0 добавили более приятный интерфейс и ускорили проверку, но основные фичи остались такими же:
Увеличенная база данных от сообщества с результатами сжатия тысяч игр, чтобы проще оценивать, как хорошо примерно сожмутся игры, если данные не устаревшие. Но этот прогноз действует только для игр из Steam или EGS — если же игра находится не в Steam, или же это вовсе не игра — то прогноза сжимаемости не будет, и придётся сжимать файлы вслепую. Из‑за этого не рекомендуется сжимать более одной программы или несколько игр одновременно.
Background Watcher — служба в фоне, которая следит за папками, видит обновление игры и автоматически сжимает файлы заново, когда компьютер простаивает.
Настраиваемые списки плохосжимаемых расширений.
CompactGUI отдельно предупреждает о том, что не рекомедуется сжимать игры, поддерживающие DirectStorage API — сжатие может испортить выигрыш от прямой загрузки в GPU.
Другая программа, Compactor, написана на Rust, и до момента выхода CompactGUI бета‑версии 4.0, была самой быстрой из таких программ. У нее всё ещё есть преимущество в виде пропуска уже сжатых файлов и меньшего использования ОЗУ, но разница составляет лишь пару сотен мегабайт в памяти при сканировании огромных папок. В ней тоже есть примитивная фильтрация в виде простой хэш‑базы с кэшем уже проверенных несжимаемых файлов, чтобы повторные запуски по той же папке проходили быстрее.
У обоих инструментов есть общие недостатки.
Нет предварительной оценки сжимаемости файлов, и никак не опознаются плохо сжимаемые файлы, если они постоянно заменяются — а в условиях повсеместно встречающихся программ на Electron, с кэшами по пару гигабайт каждая, это происходит гарантированно.
В этих программах можно только взять одну папку, выбрать один алгоритм на всю папку, и сжать всё подряд одним алгоритмом. Но в зависимости от размера файла и от мощности компьютера, использовать лучше всего только определённые алгоритмы. LZX — не панацея.
Нет кнопки типа «нажал и забыл».
Пользователю с ходу не понять, какой алгоритм и для чего использовать — потянет ли его слабый новый игровой ноутбук алгоритм XPRESS4K, или мощнейший бюджетный китайбук на Intel Celeron алгоритм LZX. Это должна выбирать сама программа.
Поэтому я однажды решил создать пет‑проект, который эти все принципы осуществляет, чтобы как сисадмину иметь возможность выбрать определённые директории, без разбора сжать всё что надо, и выполнить это сразу на десятках компьютеров. Это всё началось с возможности подбирать алгоритмы, но потом постепенно углубляясь в эту сферу, масштаб увеличивался и добавлялось всё больше и больше фич. Под конец всё оказалась таким хорошим, что удалось создать такую программу, которая превосходит всё, что существовало до этого.
Делаем это
trash‑compactor (прямая ссылка для скачивания здесь, плюс если не работает первая ссылка) имеет два режима работы:
Графический интерфейс для рядовых пользователей ПК
Консольный интерфейс, чтобы различным сисадминам можно было создавать задачи с Планировщиком Задач в Windows или скрипты, которым надо запустить программу на большом парке компьютеров на Windows
Однако 99% пользователям понадобится лишь графический интерфейс, чтобы один раз в полгода нажать на кнопку для сжатия программ и игр, и забыть.
В графическом интерфейсе, можно выбрать два пути:
Быстро сжать файлы в часто используемых папки, таких как Program Files, AppData и Downloads, а также сжать файлы Windows через функцию CompactOS, встроенную в саму Windows, чтобы системная папка Windows занимала в среднем на 30–40% меньше места на диске.
Выбрать свою папку для сжатия. Можно сжимать как на системном томе, так и на сторонних дисках — главное, чтобы файловая система была NTFS, а не exFAT и тому подобное
Во всех случаях, ни один файл не удаляется с диска, и не изменяется на уровне самого файла. При копировании сжатых папок в другое место, будь то на флешку или на другой компьютер, копия этого файла на другом носителе будет в разжатом состоянии — следовательно, можно на диске 256ГБ хранить де юро 320ГБ информации.
Не все файлы хорошо сжимаются. Плохо сжимаются:
архивы, фото, видео, аудио, и прочие файлы, которые сами по себе являются сжатыми;
документы для Word, Excel, PowerPoint в форматах
docx,xlsx,pptx,pdf‑документы и прочие документы, которые сами по себе находятся в сжатом состоянии;пакеты
gguf,safetensors,torchи другие пакеты для машинного обучения и ИИ;образы для виртуальных машин (они полностью разожмутся, как только произойдёт запись данных в образ);
файлы различных необычных форматов (в том числе установленные игры), сами по себе являющимися сжатыми данными.
Для распознавания всех таких файлов, в программе реализован инструментарий анализа папок. Он основан на проверке расширений файлов. А когда списка расширений, связанных с плохо сжимаемыми файлами, начинает нехватать — в бой идёт проверка энтропии Шэннона у файлов, в рамках которой часть файлов предварительно сжимается в нескольких случайных местах (не целиком) через самые быстрые алгоритмы сжатия, без какой‑либо записи информации на диск, чтобы не изнашивать SSD. Этой продвинутой и быстрой проверкой (которой нет у аналогов) точно определяется процент сжимаемости файлов, и если он хорошо сожмётся — то его можно будет сжать подходящим алгоритмом, если запустить сжатие.
Как это выглядит на практике:
Благодаря этой многогранной автоматизации, нет необходимости гадать, как хорошо сожмётся папка, не нужно тратить время на сжатие разных папок или игр по отдельности, или на добавление плохо расширяемых файлов. Сжать может даже неуверенный пользователь ПК. Есть даже отдельная проверка мощности компьютера — если компьютер слабый или старый, то будут использоваться только лёгкие способы сжатия, чтобы он не становился медленнее от сжатия программ или игр.
Если позволить себе немного пафосности, эта программа — самый близкий аналог тех программ, из 90-х и 2000-х, которые нажатием одной кнопки «скачивали больше оперативной памяти», однако тут всё происходит наяву, и подвохов нет — потому что исходный код программы полностью открыт.
Подноготная (кому очень интересно)
Обход и классификацию файлов выполняет созданное поддельным интеллектом (единственно правильный подход для бесплатных малоизвестных пет‑проектов) расширение «fast_walk», прикрученное к питоновскому проекту, написанное на Rust с использованием PyO3 и rayon. При сборке модуль собирается в wheel и встраивается в исполняемый файл. Многопоточное сканирование применяет фильтры расширений, определяет подходящий алгоритм сжатия в зависимости от размера файла, проверяет атрибуты NTFS через GetFileAttributes чтобы определить и не сжимать уже сжатые файлы.
После предварительного сканирования, в каждой директории выбирается ~50 файлов; для каждого читает динамическое число окон по 16 КБ. Позиции окон для сжатия выбраны так, чтобы избегать заголовков и футеров у файлов, где хранятся несжатые данные, и было значительно меньше ложноположительных результатов анализа. Для оценки плохо сжимаемых файлов, используется самый лёгкий алгоритм LZ4, для быстрого отсеивания несжимаемых фалйов. Если они сжимаются, то эти окна файлов сжимаются второй раз алгоритмом ZLIB уровня 2. После этого, подсчитывается средняя статистика сжатия файлов в директории. Если значение ниже порога в 15% (можно менять в настройках), то эта директория целиком пропускается, и файлы кэшируются как плохо сжимаемая по xxhash64 полного пути в incompressible.db.
На практике, это с точностью выше 95% позволяет отфильтровать директории, где находятся кэши программ, где под капотом используется Electron — эти кэши составляют по несколько гигабайт у каждой программы, и из примеров таких программ — любые браузеры, программы Discord, Telegram, Slack, Microsoft Teams, Visual Studio, VSCode, Cursor, Notion, Figma, WhatsApp, Obsidian, Spotify, 1Password, Postman, Docker Desktop, Beekeeper Studio, GitHub Desktop, Trello, Joplin, Twitch Desktop... В общем, вы поняли, откуда ноги растут, и что произойдёт, если вслепую пытаться сжать то, что совершенно не сжимается и постоянно меняется.
При сжатии, Windows 10 и 11 дают возможность сжать файлы такими алгоритмами, которые программа выбирает самостоятельно:
XPRESS4K (наиболее лёгкий)
XPRESS8K
XPRESS16K
-
LZX (наиболее мощный и тяжёлый)
Для файлов размером <64 КБ — XPRESS4K, <256 КБ — XPRESS8K, <1 МБ — XPRESS16K, выше — LZX по умолчанию, кроме случаев, когда компьютер оказывается слишком слабым.
LZX — словарный алгоритм на базе LZ77 с Huffman‑кодированием, который использует больший эффективный словарь, чем XPRESS с окнами 4/8/16 КБ, Он даёт более высокие коэффициенты на исполняемых файлах, DLL и ресурсах, и он умеет сжимать то, что может очень плохо сжиматься алгоритмами XPRESS.
Но LZX не подойдёт для слабых компьютеров, имеющих плохую производительность в однопотоке. Мощность компьютера автоматически проверяется на старте в однопоточном бенчмарке производительности, где симулируется декомпрессия. Если компьютер не укладывается в 0.25 секунд, то он недостоин использовать LZX, и везде будут использоваться алгоритмы XPRESS. Xeon'щикам не о чем беспокоиться — несмотря на множество ядер, их процессоры гарантированно провалят этот тест.
Комментарии (44)
VladSMR
24.08.2026 18:13Интересно, почему файловая система называется NTFS, а не XPFS, если впервые появилась в ХР?
Не в Windows ли NT она появилась )))) ?
wiki7979
24.08.2026 18:13Сначала была создана windows NT, которая представила NTFS, затем через два года появилась windows xp
Darkness_Paladin
24.08.2026 18:13Почти так. Сначала в 1993м году появилась WinNT 3.1 с нтфс, потом через восемь лет, в 2001, появилась ХРюшка.
strvv
24.08.2026 18:13Не пугайте зумеров, у НТ и НТФС был предок, почему сразу версия 3.1 и пишут что ОС появилась, о, ужас, в 1986 году. Правда это МС как всегда примазалась к чужому труду. То была HPFS, имеющая, кстати, тот же код на MBR разметке диска и ОС была полуОс, или OS/2 фирмы голубой гигант. Без мамы в директорате которой и не было бы “гения” мальчика Билли.
Darkness_Paladin
24.08.2026 18:13И что это меняет? NTFS, как публично доступная технология, была презентована в 93м году, в виде компонента ОС Windows NT 3.1
Wolf4D
24.08.2026 18:13А если диск полетит, сможет ли какая-нибудь программа восстановить такую сжатую файловую систему?
evgen_b
24.08.2026 18:13Начиная с Windows 7 использую сжатие для каталогов Windows и Program Files (но не пользовательских). Примерно в 2 раза утрамбовывается. Однако сжатие на каталог наследуется на все вложенные объекты, и все, что в нем будет создано (тут есть нюанс, какая для новых файлов компрессия применится, но не суть важно). Поэтому после сжатия нужно явно "разжать" некоторые вложенные файлы и каталоги, в которых идет запись, такие как реест, например. Все это делается из Windows PE батником, какие файлы и каталоги таким способом нужно "добавить в исключения" - находится периодическим методом тыка, например, по дате изменения, в то же время понятно, что каталоги с EXE и DLL фактически read-only (если не считать обновления, но тут у кого какие приоритеты).
mvv-rus
24.08.2026 18:13Как всегда, программисты Microsoft внедрили полу‑меры, но до ума эту технологию не довели, чтобы сжимать данные по‑умному, а не всё, что попало.
Всё они до ума довели - просто не все пользователи в курсе. Факт сжатия указывается в атрибуте, который есть не только у диска, но и у папки, и у файла. И в Проводнике этот атрибут доступен, как минимум с XP(SP3, ничего более старого у меня под рукой нет, чтобы проверить). Для работы из командной строки/пакетных файлов имеется команда compact.exe (в XP она тоже есть).
PS И да, сжатие появилось ещё в незапамятные времена, согласно Випидедии - в NT3.51 (я эту версию не застал, мое знакомство с NT началось с NT 4 SP3).
PPS То, что вы написали программу - это хорошо. Но писать то, что вы точно не знаете, не стоило IMHO.
misha1350 Автор
24.08.2026 18:13Флажок сжатия разумеется есть (если бы подноготную всю распространил везде, на этой статье простого уровня, представьте как было бы больно эту простыню читать), файловая система конечно же будет знать, что уже сжато, а что не сжато. Но можно было хотя-бы сделать простое отсеивание файлов мультимедиа по расширению .jpg и .mp3, например. В этом и полу-мера, что можно сжать все файлы, даже те, которые не надо сжимать вообще. Это не панацея.
Но писать то, что вы точно не знаете, не стоило IMHO.
"Я, знаешь ли, лучший в своём классе член отряда Navy Seals, участвовал в многочисленных секретных рейдах против «Аль-Каиды*» и имею более 300 подтверждённых~~~.........."
mvv-rus
24.08.2026 18:13Но можно было хотя-бы сделать простое отсеивание файлов мультимедиа по расширению .jpg и .mp3, например.
Можно. И сделано: как минимум, команда compact издавна принимает в качестве аргумента шаблон имени файла. Не помню, что там со сжатием в GP preferences (я его не помню, а поднимать виртуалку с КД мне сейчас лень), но уж в logon script-то команду compact воткнуть и дальше с ней работать можно точно. Ну да, это не GUI, но профессиональные администраторы работают именно с этими инструментами, а не с GUI-программами. То что вы написали программу с GUI - это хорошо, но в в дистрибутиве самой системы эта программа избыточна: для простых пользователей предназначен Проводник, для администраторов - Group Policy и скрипты. Ну а программы типа вашей - они для продвинутых пользователей, со специфическими требованиями. Ну, а вся идеология ПК от MS (идеология открытой платформы) - она ориентирована на то, что подобные программы для удовлетворения специфического спроса пишут те, кому нужно (ну, или кто хочет заработать на этом денег, хотя сейчас заработать стало трудно).
Я, знаешь ли, лучший в своём классе член отряда Navy Seals
Не ёрничайте: вы - представитель меньшинства, продвинутых пользователей. А потому отдавайте себе отчет, что ваша точка зрения не подходит ни с обычным пользователями, которых большинство (для них это избыточно сложно, их удел - Проводник и галочки в нем), ни профессионалам, которые этих обычных пользователей обслуживают, буде те попадают в их область ответственности: профессионалы пользуются другими инструментами, и эти инструменты находятся вне вашего поля зрения (в статье, по крайней мере, и, возможно это правильно, потому как необъятное объять нельзя) , но они есть, и, в некоторой части - есть уже из коробки, откуда их можно взять и приспособить.
В этом и полу-мера, что можно сжать все файлы, даже те, которые не надо сжимать вообще. Это не панацея.
Профессионалы для этого используют скрипты (.bat-файлы и т.д.).
mixsture
24.08.2026 18:13А разве нельзя сделать так, чтобы 100МБ были близки к 100МБ? Что мешает этому? На самом деле, мешает только незнание того, что эти данные программ можно сжать. А как их сжимать?
этому мешает нежелание пользователя при каждом запуске ждать полную тяжелую распаковку. Отсюда и “нет, нельзя”. Приходится использовать алгоритмы значительно легче и шустрее.
А еще мешает крайне “тяжелое” по процессору изменение сжатых файлов. Вот когда программа хочет интенсивно писать в этот файл кучкой изменений маленьких кусочков - перепаковывать то вам придется порядочно (например, этим свойством обладают СУБД).
Gulliver22
24.08.2026 18:13Интересно, начиная с Windows 2000 встретился именно с файловой системой NTFS, а не с Windows XP, которая вышла позже на пару лет. И да, это было круто, после FAT почувствовать управление правами на файлы.
strvv
24.08.2026 18:13А вин-ту-кей это нт5.0, внезапно. И винда серии нт была с 3.1. И на их документах указывают что винда серии нт с 1986, хотя это ос/2 и hpfs, послужившая базой для NTFS.
Gulliver22
24.08.2026 18:13да-да, именно, из полуоси получили в итоге первую, как я считаю, нормальную винду, а не мастдай, которым был 95, 98 и Me.
strvv
24.08.2026 18:13Так win32 появился на нт 3.1, а win95 это попытка, успешная, поставить ось вместо дос+гуи 16бит виндовс без нт. К слову, win16 в полуоси работало лучше, стабильнее, чем сама win3.xx. Но это ты, наверняка, сам знаешь.
kometakot
24.08.2026 18:13а из‑за сжатия всего подряд, у вас без причин увеличится нагрузка на процессор и замедлится система.
Ещё давно читал, что прирост производительности диска, за счёт увеличенной пропускной способности (сжатые файлы быстрее читаются) с лихвой компенсирует повышенную нагрузку на процессор, и что даже процессоры уровня четвёртого пентиума, еле замечают распаковку на лету.
Arhammon
24.08.2026 18:13Есть противоречащий момент, у нас есть NVME которые очень быстрые, но по факту производительность в 99% задач такая же как у медленных SATA.
Ну и при работе у вас не один файл распаковывается, а очень много... Ну как бы можно наверно взят процессор помощнее, оперативной памяти побольше, ой...
Darkness_Paladin
24.08.2026 18:13Так "давно" это так и было. Иногда. Если взять старый даже по тем временам диск и залить на него файлы, которые хорошо сжимаются во много раз, то на их чтении получится хорошая экономия времени. Если же взять более-менее современный накопитель и "обычные файлы", которые сжимаются не в разы, а на проценты, заслуживающей внимания экономии пропускной способности канала не получится.
Naevus
24.08.2026 18:13О! Воспоминание разблокировано...
Впервые со сжатием столкнулся в начала 90х. Была такая программа-дравйвер Стэкер (Stacker). Она вполне приемлемо сжимала файлы. Уже после нее появился нортоновский сжиматель (даже не помню как его звали)...
Естественно - все это было под ДОС.
Ну и - ради чего этот пост пилю. Был у меня кейс, когда этот стэкер УВЕЛИЧИЛ скорость обмена данными. Причем прилично... Не верите? А вот разок пришлось собрать сборку из системы AT но с диском XT (MFM-контроллер и маленьким и тормозным диском в иса шину)... Очень тормозной диск. И очень маленький... В какой то момент кто то предложил вкорячить на него стэкер... И, О! Чудо! Вопреки ожиданиям - диск стал в полтора раза быстрее! Проанализировав результаты пришли к выводу: AT машинка (кажется еще 386sx) с распаковкой справлялась настолько быстро, что время архивации практически не влияло на результат чтения. И получалось, что диск за то же самое время читает то же самое количество байт, но после распаковки их становится в полтора раза больше... В общем - в таком виде машинка проработала довольно долго (по тем временам) - использовалась как секретарская "печатающая машинка".
Darkness_Paladin
24.08.2026 18:13А смысл? Я что, для того покупал дорогой быстрый SSD, чтоб потом пожертвовать производительностью ради нескольких дополнительных процентов объёма?
Я давненько не занимался глупостями, но, помнится, в ХРюшке включение сжатия папки виндовс замедляло загрузку в три раза, и добавляло заметных лагов работе системы. Как и сжатие %програмфайлз%. Сжимать имеет смысл только то, что ещё не сжато, нужно редко, а выкинуть нельзя -- а таких файлов совсем не так много, как кажется на первый взгляд, так что реальный выигрыш от разумно применённого сжатия составит не обещанные автором 25, а один-два процента.
misha1350 Автор
24.08.2026 18:13Для своего питомца вы может и будете использовать дорогостоящий корм, но на целом зоопарке или просто на рядовых бюджетных ноутбуках с розницы, SSD объёмом больше 256ГБ теперь будет весьма дорогим удовольствием.
Одна лишь бесплатная Dota 2 (о которой теперь знают все, в последнее время), теперь занимает без малого треть места на диске размером 256ГБ То же самое с танчиками, каэсочкой, и прочими игорями. Обычная установка Windows без репака от Васи займёт ~60ГБ места на диске. 1-2 игры, десяток программ, и места уже не будет. Вот тут то и нужно сжатие и игр, и программ, и AppData, и самой Windows. Тем более, что Dota 2 сжимается аж на 35ГБ - ну вплоть до ближайшего обновления игры, которая может поменять и перезаписать половину из этого приобретённого места.
В Windows XP таки проблема как всегда со старым тяжёлым алгоритмом, медленными компьютерами, жёстким диском и т.д., но сейчас эти все проблемы исправлены, и во-вторых сейчас люди живут в кризисные времена (ну кроме нас с вами, конечно же).
mixsture
24.08.2026 18:13Тем более, что Dota 2 сжимается аж на 35ГБ - ну вплоть до ближайшего обновления игры, которая может поменять и перезаписать половину из этого приобретённого места.
понимаете, это сэкономленное место как бы есть, но как бы его и нет - и от него вреда больше, чем пользы. Пользователь вот смотрит, что у него 50 гигов свободно - качает туда фильмы. Потом прилетает обновление доты и останавливает всю систему из-за исчерпания диска до нуля. При чем, для пользователя ничего не предвещало беды - дельта с прошлой папкой доты - ну пару гигов всего.
А если мы начинаем задумываться и резервировать пустое свободное пространство под эти случаи…то чем это отличается от занятого пространства?
Darkness_Paladin
24.08.2026 18:13Вот таки да! Хорошо, когда это место есть -- но увы, квалифицированно им воспользоваться может только технически грамотный человек, понимающий, что он делает и зачем.
Вот я вручную сжимаю некоторые папки и даже некоторые отдельные файлы -- и нет проблем. Я знаю, какие именно, зачем и чем это чревато, и у меня не возникает никаких проблем. А если пользователь бездумно будет плющить всё подряд, или доверит эту тончайшую работу бездушным скриптам, рано или поздно будет "упс".
misha1350 Автор
24.08.2026 18:13Поэтому от игр типа Dota 2 сплошной вред.
Но если ставить множество игр, которые не обновляются каждую неделю, например одиночные игры или просто те игры, у которых карты/данные/итд не меняются больше нескольких месяцев (например тот же полудохлый но всё равно весьма популярный Team Fortress 2 и его множество скачиваемых пользовательских карт, которые никогда не чистятся, никогда не обновляются (ведь масштабные обновления базовой игры не приходят), и при этом могут забить легко 35-40ГБ+ на диске, хотя игра сама весит лишь 25-30ГБ), то польза идёт большая от этого. А от сжатия забытых программ в недрах Program Files и AppData - тем более. Лучше подумать о других сценариях, кроме как одной лишь игры типа Dota 2.
Moog_Prodigy
24.08.2026 18:13В вин95 была системная утилита Double Space (она же DriveSpace), вполне себе была актуальна на те времена, когда диск 100 мб считался нормальным.
Zhuravlev-A-E
24.08.2026 18:13Не туда копаете:
всего-то нужен простой советский...)
DOS (c):
"... DOS очистил все,
Все, что было лишним у меня на диске C:
Я нажал F8
И веселый Нортон удалял мне все подряд:
Сорок мегабайт.
Может даже больше, может даже шестьдесят ..."
mixsture
24.08.2026 18:13SSD на 256ГБ остаются в пределах досягаемости по цене из‑за их распространённости
Что такое “досягаемость”? цена за единицу объема обычно падает с повышением емкости накопителя.
Darkness_Paladin
24.08.2026 18:13Не совсем так. График цена-качество (независимо от того, в каких единицах вы это качество выразите) любого товара практически всегда имеет вот такой вот вид:
Типовой график зависимости цена-качество
Типовой график зависимости цена-качество То есть, "на дне" (сегмент А) нет смысла переплачивать: за бОльшие деньги вы получите такой же плохой продукт, как и за меньшие. Оптимум для покупки -- это сегмент С: качество эффективно растёт вместе с ценой, вы можете купить настолько хороший продукт, насколько вам хватит бюджета. Сегмент Е -- опять нет смысла переплачивать, рост цены уже не даёт заметного прироста качества. Ну и сегменты В и D -- ни то, ни сё. Товары из этих сегментов лучше не брать, а взять что-то повыше (если вам важнее качество) или пониже (если важнее стоимость).
Так вот, в случае с ссд, накопители на 256гб сейчас находятся где-то в сегменте А.
liyafomina
24.08.2026 18:13Идея сжатия на уровне файловой системы старая, как мир. Винда уже 25 лет это умеет, но они забили, потому что жрёт проц и убивает SSD
misha1350 Автор
24.08.2026 18:13Именно этого я касался в статье. Пора вспомнить про сжатие снова, потому что все минусы уже исправлены более мощным железом и более правильными алгоритмами, а подбадривает к этому и текущее положение не только с жадными корпорациями, но и с огромной кучей аутсорснутого вайб-кода, раздувающего софт до каких-то невиданных доселе размеров. А ещё разумеется не стоит использовать топорные решения, которым 25 лет в обед, со времён Windows XP. Сжимать весь диск совершенно неразумно. Собственно об этом всём и написано в статье, и я хотел показать, что мы имеем сейчас, и каким образом оно лучше, и как сделать это ещё лучше и проще.
Darkness_Paladin
24.08.2026 18:13Сжимать весь диск совершенно неразумно.
Как и сплошняком папки виндовс, программфайлз и аппдата. Сжимать надо исключительно вручную, с пониманием, что и зачем сжимаете. Вот, скажем, аппдата/ардуино у меня сжата -- потому что выгоды от сжатия много (почти пять гигов в моём случае), а вред ничтожен, я редко пользуюсь ардуино ИДЕ. Фотошоп и офис в програмфайлз сжаты, потому что выгода есть, а вред мал. А вот папка "загрузки", несмотря на значительный объём, у меня не сжата -- я её просто на отдельный терабайтный hdd линканул, небыстрый, зато довольно дешёвый. Да и смысла нет её сжимать, там файлы в основном уже упакованные куда более мощными средствами.
misha1350 Автор
24.08.2026 18:13Я именно к этому и пришёл, и в своей программе сделал простой анализ кусочков файлов через их сжатие, чтобы таким образом подсчитать энтропию файлов. С таким подходом также удастся быстро и достаточно точно предугадать, до какого размера сожмутся файлы таким-то таким-то алгоритмом.
Если файл - архив, картинка, или просто случайные файлы которые уже хранят сжатые данные, то первые два типа отсеются по их расширениям .zip или .jpg, а у третьего типа файлов, в таком исключительном случае, будут взяты несколько маленьких окошек из разных частей файла, чтобы сжать их очень быстрым алгоритмом и определить, сжимается ли он вообще, или нет. Если окошки хорошо сжимаются, например более чем на 15% - то файл будет кандидатом на сжатие.
Теперь можно благодаря ей сжимать и "Загрузки", и "AppData" с огромной кучей кэша типа Electron или Chromium (который уже хранится сжатым), и вообще весь диск. Если взять ~50 таких разных компьютеров и ноутбуков, у которых диски могут быть мелкие, можно одним нажатием сжать весь диск именно там, где нужно. Вот такой юзкейс я вижу, и на мелких дисках это сильно спасает, особенно когда не вариант тратить по 10-15 минут на то, чтобы сжимать всё избирательно. Да и благодаря тому, что сжимается далеко не всё (когда у тебя в сжимаемой папке сборная солянка из сжимаемых и несжимаемых файлов), скорость работы на старых/картофельных компьютерах или ноутбуках не страдает так сильно, как старыми способами.
Shrizt
24.08.2026 18:13Имхо может и полезная штука, надо попробовать, сжимать тупо все подряд действительно глупо, никогда не пользовался. А выбирать руками тоже хрень. Спасибо автору, прижмеи - проверю ))
dartraiden
24.08.2026 18:13Можно ещё прикрутить дедупликацию (выдрав компонент из винсервера). Или поиграть в энтерпрайз и перейти на ReFS, где и сжатие и дедупликация есть на уровне ФС "из коробки". Но это не для системного раздела, конечно. Плюс поддержка DirectStorage отвалится.
alex09102026
Это гениально! и вы таки не поверите, но сжимать можно даже отдельные каталоги!
misha1350 Автор
Жаль только что попытка сжать эти модели топорным способом через Проводник приведёт лишь к +254ГБ потерянного ресурса на диске в вашем случае, ведь эти .gguf не сжимаются вообще.
Представьте теперь зоопарк из ~30-50 разных компьютеров в условном офисе, ВУЗе или школе, где стоят забитые 250ГБ диски SATA. У меня такой кейс уже был минимум один раз. У нас было так, что надо было загружать большой комплект софта на зоопарк - и наши эникейщики даже не понимали, что ломается установка у них потому что на диске C осталось 0 байт свободного места на SSD. Умножьте ~15 минут, потраченных на каждый такой забитый компьютер, чтобы он стал как ваш питомец, а не как зоопарк скотины (опять это клише...), чем он и должен быть, и вы так целый день потратите на то, что сделать довольно просто на бумаге.
О старых ноутбуках 2-в-1 типа Lenovo на Celeron, с 4ГБ ОЗУ и 128ГБ вечнозабитого eMMC хранилища я вообще молчу. И нет, выкидывать их не вариант, они всё ещё работают.
Топорный метод приводил к ~50 минутам на сжатие в одном потоке устаревшим излишне тяжёлым алгоритмом который сжимал всё подряд, даже то что не надо. Накипело так, что теперь усердно и без стыда рекламирую свой пет-проектик, чтобы такого не пришлось другим испытывать.