Недостаточно места на диске при ошибке «Корень файловой системы» в openSUSE Leap 15

872
Human

проблема

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

Анализ

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

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

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

0

2 ответа на вопрос

0
Server Fault

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

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

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

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

  • купить новый жесткий диск. Та же емкость или больше. подключите его и создайте большие разделы (если возможно, используйте LVM). Первый раздел на новом диске должен быть размером 1G (может быть меньше, если кратко) и предназначен для совместимости с 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 запутывается в вещах. Должны быть более простые способы сделать это.

0
Kamil Maciorowski

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

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

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

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

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

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

    snapper list

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

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

    snapper delete 65

Но также:

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

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

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

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

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

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

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

  • вы полностью пропустили /.snapshotsкаталог, скорее всего, он отвечает за большую часть используемого пространства;
  • Снимки Btrfs, вероятно, участвуют;
  • Снаппер, вероятно, участвует.
Снаппер не удалил 65, поскольку в списке Снапперов не было ни одного элемента с 65. Разве 65 не должен быть в списке? Human 5 лет назад 0
@Human Это всего лишь пример ... Kamil Maciorowski 5 лет назад 0

Похожие вопросы