Problema

Question

Problema

Aparentemente, estou com pouco espaço em disco na minha partição raiz. Na hora de instalar meu SO (openSUSE Leap 15 em uma VM) escolhi o particionamento padrão. Agora recebo o aviso/erroPouco espaço em disco na "raiz do sistema de arquivos". Ele me avisa quando inicio o sistema e quando tento compilar um projeto grande gera um erro.

Análise

Vamos verificar a situação do armazenamento:

relatar o uso do espaço em disco do sistema de arquivos:

$ 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

Estimar o uso do espaço no arquivo:

$ 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

Listando instantâneos como sugerido por @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

Também ouvi falar de Kernels antigos não utilizados, então verifiquei e descobri isto:

$ 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

Ideias para uma solução:

1. Redimensione a partição raiz. (dar mais 10 shows ao root seria bom)
2. Excluir a versão antiga do kernel e espero não quebrar as coisas e os 245 MB liberados serão suficientes por enquanto.

Eu realmente prefiro dar mais espaço ao root, mas não tenho ideia de como fazer isso ou se é uma boa ideia mexer com isso. Que solução você proporia e como posso fazer isso?

Answer 1

/dev/sda2montado em pontos de montagem diferentes (onde você deveria ter conteúdo diferente) me faz acreditar que você está usando o Btrfs. Você também /.snapshotsmontou o que indica a presença dePargo. É altamente provável que /.snapshotsocupe a maior parte do espaço usado.

Observe que sua análise du -hsx /*nem foi levada /.snapshotsem consideração porque *glob não se expande para nomes começando com ..

Não tenho experiência com Snapper. Eu suspeito que existam subvolumes Btrfs (shapshots) dentro de /.snapshots. O comando du -hsx /.snapshotspode até retornar 0por causa da -xopção utilizada. Por outro lado, du -hs /.snapshotsprovavelmente retornará um valor enorme. Pode ser muito maior que o tamanho de /dev/sda2(que é 40GiB) porque você provavelmente tem vários instantâneos que compartilham espaço em disco (é assim que o Btrfs funciona), ainda assim duos considerará como sistemas de arquivos separados.

Para analisar mais detalhadamente, você precisa de ferramentas específicas do Btrfs e/ou Snapper. Tenho alguma experiência com Btrfs, mas não com Snapper. Não sei dizer se você pode confundir o Snapper alterando manualmente os instantâneos que ele criou, pode ser possível; mas tenho certeza que você não pode quebrar o Btrfs usando o Snapper. Portanto, a abordagem segura é lidar com a situação com tudo o que o Snapper fornece, não diretamente com as ferramentas Btrfs.

O tutorial já mencionadonos dá algumas dicas sobre o que você pode fazer:

• Listar todos os instantâneos da configuração padrão (raiz)

  snapper list
  

• Excluindo instantâneos

  Exclua o snapshot 65 para a configuração padrão (raiz):

  snapper delete 65
  

Mas também:

Mecanismos automáticos de limpeza de instantâneos

Para evitar que o espaço em disco fique cheio, o Snapper limpa periodicamente os instantâneos. Por padrão, este período = 1 dia.

A tarefa de limpeza automática de instantâneos pode ser gerenciada de duas maneiras:

1. agendador cron ( /etc/cron.daily/suse.de-snapper).
2. agendador de timer systemd ( snapper-cleanup.timere snapper-cleanup.serviceunidades systemd).

Por padrão, o mecanismo cron está em uso.

Talvez algo tenha falhado com esse mecanismo de limpeza?

Como eu disse, não tenho experiência com Snapper, então não posso ajudá-lo mais. No entanto, se eu estiver certo, agora você sabe o que investigar. Para resumir:

• você perdeu totalmente /.snapshotso diretório, provavelmente ele é responsável pela maior parte do espaço usado;
• Os instantâneos do Btrfs provavelmente estão envolvidos;
• Snapper provavelmente está envolvido.

Answer 2

A primeira coisa a fazer é fazer um backup de tudo que é importante. Ir mais longe nesse caminho envolve fazer coisas que podem resultar em perda de dados. Algumas opções abaixo:

• compre um novo disco rígido USB SATA. Troque a unidade USB SATA pela unidade antiga no seu gabinete. Reinstale o Linux na nova unidade SATA. Sempre que precisar acessar seus arquivos antigos, conecte o drive USB e lá estão eles.

• Se você particionou usando LVM (o que o SuSE provavelmente não fez), então veja se você pode estender ( lvmresize -L+10G /dev/mapper/whatever) sua partição de barra e então redimensionar ( resize2fs /dev/mappper/whatever). Esta é a solução mais fácil.

• se você tiver partições rígidas (por exemplo: root is on /dev/sda1), você pode tentar inicializar com o Gparted Live (https://gparted.org/livecd.php) e brincar tentando estender sua partição rígida. Geralmente, o sucesso aqui depende de quanto espaço livre resta em sua unidade e como você particionou as coisas

• compre um novo disco rígido. Mesma capacidade ou maior. conecte-o e crie partições maiores (use LVM se possível). A primeira partição no novo disco deve ter tamanho de 1G (pode ser menor, apenas para ser breve) e existe para compatibilidade com o Grub. Depois, inicialize em seu disco antigo e crie diretórios/monte as novas partições de disco /mnt/new_disk/; sincronize novamente todas as partições antigas no novo disco. (por exemplo: rsync -av / /mnt/new_disk/slash/; rsync -av /usr /mnt/new_disk/usr/;...). Depois de terminar, você precisará instalar o grub no novo disco de alguma forma. Normalmente faço isso usando um chroot, /mnt/new_disk/slash/mas pode ser assustador. Normalmente o grub.cfg fica confuso sobre as coisas. Deve haver maneiras mais fáceis de fazer isso.