Проблема

Question

Проблема

Видимо, у меня заканчивается дисковое пространство на моем корневом разделе. Во время установки ОС (openSUSE Leap 15 на виртуальной машине) я выбрал разбиение по умолчанию. Теперь я получаю предупреждение/ошибкуМало места на диске в «корневой файловой системе». Он предупреждает меня при запуске системы, а когда я пытаюсь скомпилировать большой проект, он выдает ошибку.

Анализ

Давайте проверим ситуацию с хранением:

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

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs         13G     0   13G   0% /dev
tmpfs            13G   34M   13G   1% /dev/shm
tmpfs            13G   82M   13G   1% /run
tmpfs            13G     0   13G   0% /sys/fs/cgroup
/dev/sda2        40G   38G  2.2G  95% /
/dev/sda2        40G   38G  2.2G  95% /root
/dev/sda2        40G   38G  2.2G  95% /boot/grub2/i386-pc
/dev/sda3       204G  165G   40G  81% /home
/dev/sda2        40G   38G  2.2G  95% /boot/grub2/x86_64-efi
/dev/sda1       500M  5.0M  495M   1% /boot/efi
/dev/sda2        40G   38G  2.2G  95% /usr/local
/dev/sda2        40G   38G  2.2G  95% /srv
/dev/sda2        40G   38G  2.2G  95% /opt
/dev/sda2        40G   38G  2.2G  95% /.snapshots
/dev/sda2        40G   38G  2.2G  95% /tmp
/dev/sda2        40G   38G  2.2G  95% /var
tmpfs           2.6G   20K  2.6G   1% /run/user/462
tmpfs           2.6G   48K  2.6G   1% /run/user/1000

Оцените использование файлового пространства:

$ sudo du -hsx /* | sort -rh | head -n 40
[sudo] password for root: 
du: cannot access '/proc/8809/task/8809/fd/4': No such file or directory
du: cannot access '/proc/8809/task/8809/fdinfo/4': No such file or directory
du: cannot access '/proc/8809/fd/4': No such file or directory
du: cannot access '/proc/8809/fdinfo/4': No such file or directory
51G /home
5.5G    /usr
972M    /opt
894M    /var
792M    /lib
63M /boot
38M /tmp
24M /etc
18M /run
11M /sbin
11M /lib64
2.1M    /bin
320K    /root
0   /sys
0   /srv
0   /selinux
0   /proc
0   /mnt
0   /dev

$ sudo du -hsx /.snapshots
2.2M    /.snapshots

$ sudo du -hs /.snapshots
129G    /.snapshots

Перечисление снимков, как предложил @Kamil Maciorowsk:

$ sudo snapper list
 Type   | #   | Pre # | Date                             | User | Cleanup | Description           | Userdata     
-------+-----+-------+----------------------------------+------+---------+-----------------------+--------------
single | 0   |       |                                  | root |         | current               |              
single | 1   |       | Tue 02 Oct 2018 02:42:20 PM CEST | root |         | first root filesystem |              
pre    | 74  |       | Mon 08 Oct 2018 03:25:32 PM CEST | root | number  | zypp(zypper)          | important=yes
post   | 75  | 74    | Mon 08 Oct 2018 03:27:17 PM CEST | root | number  |                       | important=yes
pre    | 82  |       | Tue 16 Oct 2018 09:11:33 AM CEST | root | number  | zypp(zypper)          | important=yes
post   | 83  | 82    | Tue 16 Oct 2018 09:12:04 AM CEST | root | number  |                       | important=yes
pre    | 108 |       | Thu 01 Nov 2018 01:25:41 PM CET  | root | number  | zypp(zypper)          | important=yes
post   | 109 | 108   | Thu 01 Nov 2018 01:27:12 PM CET  | root | number  |                       | important=yes
pre    | 122 |       | Thu 08 Nov 2018 09:26:09 AM CET  | root | number  | zypp(zypper)          | important=yes
post   | 123 | 122   | Thu 08 Nov 2018 09:27:40 AM CET  | root | number  |                       | important=yes
pre    | 128 |       | Mon 12 Nov 2018 08:40:03 AM CET  | root | number  | zypp(zypper)          | important=yes
post   | 129 | 128   | Mon 12 Nov 2018 08:41:36 AM CET  | root | number  |                       | important=yes
pre    | 144 |       | Mon 19 Nov 2018 09:52:15 AM CET  | root | number  | zypp(zypper)          | important=no 
post   | 145 | 144   | Mon 19 Nov 2018 09:54:33 AM CET  | root | number  |                       | important=no 
pre    | 146 |       | Wed 21 Nov 2018 11:07:33 AM CET  | root | number  | zypp(zypper)          | important=no 
post   | 147 | 146   | Wed 21 Nov 2018 11:07:56 AM CET  | root | number  |                       | important=no 
pre    | 148 |       | Thu 22 Nov 2018 09:19:51 AM CET  | root | number  | zypp(zypper)          | important=no 
post   | 149 | 148   | Thu 22 Nov 2018 09:19:54 AM CET  | root | number  |                       | important=no 
pre    | 150 |       | Mon 26 Nov 2018 09:12:02 AM CET  | root | number  | zypp(zypper)          | important=no 
post   | 151 | 150   | Mon 26 Nov 2018 09:12:19 AM CET  | root | number  |                       | important=no 
pre    | 152 |       | Thu 29 Nov 2018 09:34:37 AM CET  | root | number  | zypp(zypper)          | important=no 
post   | 153 | 152   | Thu 29 Nov 2018 09:35:22 AM CET  | root | number  |                       | important=no

Я также слышал о старых неиспользуемых ядрах, поэтому проверил и нашел вот это:

$ ls -la /lib/modules
total 0
drwxr-xr-x 1 root root 108 Nov  8 09:29 .
drwxr-xr-x 1 root root  78 Oct  4 16:13 ..
drwxr-xr-x 1 root root 354 Oct 16 09:11 4.12.14-lp150.12.22-default
drwxr-xr-x 1 root root 354 Nov  8 09:26 4.12.14-lp150.12.25-default

Идеи для решения:

1. Измените размер корневого раздела. (было бы неплохо дать root еще 10 гигов)
2. Удаляю старую версию ядра и надеюсь, что ничего не сломаю, а освободившихся 245 МБ будет пока достаточно.

Я действительно предпочитаю просто дать root больше места, но понятия не имею, как это сделать или стоит ли вообще с этим возиться. Какое решение вы бы предложили и как это сделать?

Answer 1

/dev/sda2смонтировано в разных точках монтирования (где предполагается разное содержимое) заставляет меня думать, что вы используете Btrfs. Вы также смонтировали, /.snapshotsчто указывает на наличиеСнаппер. Весьма вероятно, что он /.snapshotsзанимает большую часть используемого пространства.

Обратите внимание, что ваш анализ du -hsx /*даже не принял /.snapshotsво внимание, поскольку *glob не расширяется до имен, начинающихся с ..

У меня нет опыта работы со Snapper. Я подозреваю, что внутри есть подтома Btrfs (shapshots) /.snapshots. Команда du -hsx /.snapshotsможет даже вернуть 0из-за -xиспользуемой опции. С другой стороны, du -hs /.snapshotsвероятно, вернет огромное значение. Оно может быть намного больше размера /dev/sda2(который равен 40GiB), поскольку у вас, вероятно, есть несколько снимков, которые совместно используют дисковое пространство (именно так работает Btrfs), по-прежнему duбудет считать их отдельными файловыми системами.

Для дальнейшего анализа вам понадобятся инструменты Btrfs-specific и/или Snapper. У меня есть некоторый опыт работы с Btrfs, но не со Snapper. Я не могу сказать, можно ли сбить Snapper с толку, вручную искажая созданные им снимки, это возможно; но я уверен, что вы не сможете сломать Btrfs с помощью Snapper. Поэтому безопасный подход — справиться с ситуацией с помощью того, что предоставляет Snapper, а не напрямую с помощью инструментов Btrfs.

Уже упомянутый учебникдает нам несколько подсказок о том, что вы можете сделать:

• Список всех снимков для конфигурации по умолчанию (корневая)

  snapper list
  

• Удаление снимков

  Удалить снимок 65 для конфигурации по умолчанию (корневой):

  snapper delete 65
  

Но и:

Механизмы автоматической очистки снимков

Чтобы предотвратить заполнение дискового пространства, Snapper периодически очищает снимки. По умолчанию этот период = 1 день.

Задачу автоматической очистки снимков можно управлять двумя способами:

1. планировщик cron ( /etc/cron.daily/suse.de-snapper).
2. Планировщик таймера systemd ( snapper-cleanup.timerи snapper-cleanup.serviceмодули systemd).

По умолчанию используется механизм cron.

Может быть, что-то пошло не так в этом механизме очистки?

Как я уже сказал, у меня нет опыта работы со Snapper, поэтому я не могу вам больше помочь. Однако, если я прав, теперь вы знаете, что исследовать. Подведем итог:

• вы полностью пропустили /.snapshotsкаталог, скорее всего, он отвечает за большую часть используемого пространства;
• Вероятно, задействованы моментальные снимки Btrfs;
• Вероятно, в этом замешан Снаппер.

Answer 2

Первое, что нужно сделать, это сделать резервную копию всего важного. Дальнейшее продвижение по этому пути подразумевает выполнение действий, которые могут привести к потере данных. Некоторые варианты ниже:

• купите новый жесткий диск USB SATA. Поменяйте диск USB SATA со старым диском в вашем корпусе. Переустановите Linux на новый диск SATA. Когда вам понадобится доступ к старым файлам, подключите диск USB, и они будут там.

• Если вы разбили разделы с помощью LVM (чего SuSE, вероятно, не делает), то посмотрите, можете ли вы расширить ( lvmresize -L+10G /dev/mapper/whatever) свой слэш-раздел, а затем изменить его размер ( resize2fs /dev/mappper/whatever). Это самое простое решение.

• если у вас есть жесткие разделы (например: root включен /dev/sda1), то вы можете попробовать загрузиться с помощью Gparted Live (https://gparted.org/livecd.php) и пытаетесь расширить жесткий раздел. Как правило, успех здесь зависит от того, сколько свободного места осталось на вашем диске и как вы разбили его на разделы

• купите новый жесткий диск. Такой же емкости или больше. подключите его и создайте разделы большего размера (используйте LVM, если возможно). Первый раздел на новом диске должен быть размером 1 ГБ (можно меньше, просто для краткости) и предназначен для совместимости с Grub. После этого загрузитесь со старого диска и создайте каталоги/смонтируйте разделы нового диска на /mnt/new_disk/; rsync все старые разделы на новый диск. (например: rsync -av / /mnt/new_disk/slash/; rsync -av /usr /mnt/new_disk/usr/;...). После того, как вы закончите, вам нужно будет как-то установить grub на новый диск. Я обычно делаю это с помощью chroot, /mnt/new_disk/slash/но это может быть сложно. Обычно grub.cfg путается в вещах. Должны быть более простые способы сделать это.