Битва за свободное место на диске
Как в 2023м найти очередную с#ку, сожравшую весь ваш терабайтовый диск. Unix edition.
это не про нищебродство и крохоборство — уже лет 15 как работаю только на SSD, а размер моих дисков в среднем — терабайт. Даже NAS есть.
И тем не менее даже такие чудовищные объемы легко и быстро сжираются под чистую, если не чистить.
Статья по большей части про рабочую машину для разработки ПО, на которой происходит частая сборка разнообразных проектов на различных языках.
Как найти
В любом юниксе есть две команды:
du — показывает размер отдельного каталога или файла, df — показывает оставшееся свободное место.
Когда-то давно их двоих хватало с головой, но к сожалению в реалиях современной разработки, когда каждая собака пакетный менеджер норовит выкачать пол-интернета при сборке библиотеки — простых решений уже не хватает.
Вот эта замечательная штука легко и просто покажет виноватых, останется только удалять. Есть в каждом дистрибьютиве линукса и во всех BSD.
Более того, она настолько популярна что была портирована даже под венду. Что для изначально юниксовой утилиты — редкость.
Теперь пройдемся по злачным местам.
Злачные места
Очень много чего складируется в скрытых папках домашнего каталога пользователя — большинство несистемных пакетных менеджеров загружают свое говно именно сюда.
По канону домашний каталог это /home/<дядявася> или ~/<дядявася> , но бывают и вариации.
Поскольку любимые торренты также заливаются в домашний каталог — отделить одно от другого бывает проблематично. Приходится искать.
Ниже ряд популярных мест, которые стоит проверить — это все скрытые папки (начинающиеся с точки) в домашнем каталоге.
.android
Тут будут загруженные образы виртуалок андроида, они большие.
Собственно минимальный размер ~ 20Гб (Android Studio + Gradle + Android SDK + AVD ) только для начала разработки под андроид.
Как только проект с андроидом заканчивается это все лучше всего удалить, поскольку открыв через полгода Android Studio — вы ох#еете сильно удивитесь от количества и объема обновлений.
.npm и .yarn
Разработка на Node.js требует использования пакетного менеджера — npm или yarn, как самые популярные.
В эти каталоги менеджеры заливают все скачиваемые библиотеки, которые затем копируются в папку node_modules проекта.
Мой рекорд: 20Гб для ~/.npm каталога.
.m2
Каталог с локальным репозиторием артефактов Apache Maven.
Проще говоря сюда заливаются все библиотеки Java/Kotlin/Scala проектов при сборке мавеном.
Еще есть использование Maven в качестве встроенного решения, так например делает JBPM, поэтому данная папка может появиться и вырасти даже если вы вроде-бы ничего не собираете.
15-20Гб легко и просто при сборке пары больших проектов.
.gradle
У Gradle есть замечательная особенность в виде выкачивания своего дистрибьютива нужной версии перед запуском сборки. Каждый из них ~200 Мб.
Плюс тут хранятся репозитории с выкачанными библиотеками, в том числе при мобильной разработке под андроид.
.idea , .eclipse и .netbeans
Три сестры-подружки, жрущие место в три горла:
скрытые каталоги, где три самые популярные среды разработки Intellj Idea, Eclipse и Netbeans хранят своинаворованныеданные.
Все три делают копию внутренней структуры для каждой своей минорной версии, мигрируя данные при апдейтах.
Все три хранят там полнотекстовые индексы для исходников и библиотек:
Один дамп (zip архив) с индексами для Central Maven Repository занимает ~600Мб и он такой не один.
Вообщем при реальной работе, эти каталоги будут по 10-15 Гб каждый.
Экзотика
Ниже списком различная экзотика, которая при активном использовании также может сильно разрастаться.
Это все тоже каталоги в домашней папке пользователя:
- .dotnet — Microsoft .NET, внутри будут папки с версиями;
- .nuget — сюда складируются пакеты dotnet/mono после скачивания;
- .cabal — Cabal, пакетный менеджер для Haskell;
- .cpan — Perl и CPAN;
- .rvm — Ruby и его пакетный менеджер RubyGems.
LLVM
Удивительно, но бинарные сборки LLVM какие-то чудовищно большие — в районе 1Гб за версию.
А с учетом того что есть софт (например KDevelop), у которого какая-то определенная версия LLVM указана в виде зависимости — сожрать места она диске оно может очень много.
snapd
Вообще это такой контейнер и поэтому несколько отдельная песня.
Но поскольку в какой-то момент в Ubuntu а затем и в других дистрибьютивах решили поставлять браузер Chrome/Chromium в виде snap образа - очень широкой массе пользователей пришлось насильно с ним познакомиться:
I was using Disk Usage Analyzer recently to see if I could free up some space on my Ubuntu 18.10 desktop, when I noticed that the /var/lib/snapd/snaps/
folder was quite large. [#]
Вообщем оно жрет место как не в себя, сохраняя старые версии образов.
Поэтому нужно сначала отключить сохранение старых версий:
snap set system refresh.retain=2
#!/bin/bash # Removes old revisions of snaps # CLOSE ALL SNAPS BEFORE RUNNING THIS set -eu LANG=ru_RU.UTF-8 snap list --all | awk '/disabled/{print $1, $3}' | while read snapname revision; do snap remove "$snapname" --revision="$revision" done
Кеш пакетов
С какого-то хера по великой задумке гениальных авторов, все устанавливаемые в систему пакеты кешируются локально:
Устанавливаете пакет JDK, который весит 300Мб, он скачивается, сохраняется локально затем распаковывается в каталоги системы. Но копия скачанного пакета при этом не удаляется.
Некоторые особо умные хранят еще и по несколько версий.
Вообщем это все очень быстро разрастается, особенно если постоянно ставить и обновлять всякие библиотеки разработки.
Ниже примеры команд очистки кеша пакетных менеджеров.
sudo apt-get clean
yum clean all
Все загруженные пакеты складируются в /var/cache/pkg, которая постоянно растет. Для очистки необходимо выполнить:
pkg clean -a
Это лишь малая часть любителей сожрать место, на практике вариантов куда больше и сами варианты — разнообразнее.