unix
February 26, 2023

Битва за свободное место на диске

Как в 2023м найти очередную с#ку, сожравшую весь ваш терабайтовый диск. Unix edition.

Нужно больше места!

Скажу сразу:

это не про нищебродство и крохоборство — уже лет 15 как работаю только на SSD, а размер моих дисков в среднем — терабайт. Даже NAS есть.

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

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

Как найти

В любом юниксе есть две команды:

du и df

du — показывает размер отдельного каталога или файла, df — показывает оставшееся свободное место.

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

Поэтому придумали сложное:

QDirStat, в девичестве K4DirStat, еще раньше - KDirStat

Вот эта замечательная штука легко и просто покажет виноватых, останется только удалять. Есть в каждом дистрибьютиве линукса и во всех 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Мб, он скачивается, сохраняется локально затем распаковывается в каталоги системы. Но копия скачанного пакета при этом не удаляется.

Некоторые особо умные хранят еще и по несколько версий.

Вообщем это все очень быстро разрастается, особенно если постоянно ставить и обновлять всякие библиотеки разработки.

Ниже примеры команд очистки кеша пакетных менеджеров.

Ubuntu, Debian:

sudo apt-get clean

RHEL, CentOS:

yum clean all

FreeBSD:

Все загруженные пакеты складируются в /var/cache/pkg, которая постоянно растет. Для очистки необходимо выполнить:

pkg clean -a

Это лишь малая часть любителей сожрать место, на практике вариантов куда больше и сами варианты — разнообразнее.

Но надеюсь в качестве вводного материала этого хватит )