Eu tenho um computador openSUSE que começou com o BtrFS cedo (como o Leap 42.2). Em um momento no passado, o subvolume /tmp ficou cheio (um arquivo grande) e não consegui recuperar espaço até a reinicialização ( rm
acionou um No space left on device
). Então tudo parecia bom por pelo menos um ano.
Mas recentemente (entretanto no Leap 15.1) o BtrFS ficou cheio novamente e eu me perguntei o que fazer: eu tinha muitos snapshots como este:
# ls -l /.snapshots/
total 4
drwxr-xr-x 1 root root 32 Dec 18 2015 1
drwxr-xr-x 1 root root 32 May 14 09:45 1820
drwxr-xr-x 1 root root 66 May 14 09:46 1821
...
drwxr-xr-x 1 root root 32 Aug 8 08:08 1926
drwxr-xr-x 1 root root 38 Aug 8 08:09 1927
drwxr-xr-x 1 root root 38 Aug 8 08:12 1928
Depois de ter verificado todos os checksums dos blocos com sucesso (sem problemas) iniciei um "balanço" esperando que aparecesse algum espaço livre. Mas o equilíbrio parecia nunca terminar, então tentei abortá-lo. Depois de esperar pelo menos 15 minutos para o equilíbrio ser abortado, reiniciei o computador para tentar outra coisa. Naquela época, o sistema de arquivos estava 99% cheio.
Pensei em limpar o snapshot mais antigo ( 1
) usando rm -rf /.snapshots/1
. Infelizmente, depois de terminar, os programas essenciais /usr
desapareceram e meu sistema não inicializou!
Portanto, minha pergunta é: esse comportamento é esperado ou fiz algo errado? Se eu fiz algo errado, qual é o procedimento correto para remover instantâneos antigos?
Responder1
Parece que os problemas observados após a remoção /.snapshots/1
não são tanto um recurso do BtrFS por si só, mas um recurso (errado?) do SUSE Linux:
Não me lembro qual era o sistema de arquivos raiz, mas em um sistema SLES 15.0 comparável notei que o snapshot 1
foi montado como sistema de arquivos raiz (por qualquer motivo):
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
devtmpfs on /dev type devtmpfs (rw,nosuid,size=16329060k,nr_inodes=4082265,mode=755)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,size=24506344k)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
#...
/dev/sda2 on / type btrfs (rw,relatime,space_cache,subvolid=267,subvol=/@/.snapshots/1/snapshot)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=38,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=14427)
#...
/dev/sda2 on /.snapshots type btrfs (rw,relatime,space_cache,subvolid=266,subvol=/@/.snapshots)
/dev/sda2 on /opt type btrfs (rw,relatime,space_cache,subvolid=263,subvol=/@/opt)
/dev/sda2 on /usr/local type btrfs (rw,relatime,space_cache,subvolid=259,subvol=/@/usr/local)
/dev/sda2 on /var type btrfs (rw,relatime,space_cache,subvolid=258,subvol=/@/var)
#...
/dev/sda2 on /root type btrfs (rw,relatime,space_cache,subvolid=262,subvol=/@/root)
tmpfs on /run/user/0 type tmpfs (rw,nosuid,nodev,relatime,size=3267512k,mode=700)
Essa subvol=/@/.snapshots/1/snapshot)
parece ser a causa raiz.