Tengo una computadora openSUSE que comenzó con BtrFS temprano (como Leap 42.2). En un momento del pasado, el subvolumen /tmp se llenó (un archivo grande) y no pude recuperar espacio hasta que reinicié ( rmse había activado un archivo No space left on device). Luego todo parecía ir bien durante al menos un año.
Pero recientemente (mientras tanto en Leap 15.1) BtrFS se llenó nuevamente y me preguntaba qué hacer: tenía muchas instantáneas como esta:
# 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
Después de haber verificado exitosamente las sumas de verificación de todos los bloques (sin problemas), comencé un "saldo" con la esperanza de que apareciera algo de espacio libre. Pero el equilibrio nunca pareció terminar, así que intenté abortarlo. Después de esperar al menos 15 minutos para que se cancelara el saldo, reinicié la computadora para intentar algo más. En ese momento el sistema de archivos estaba lleno al 99%.
Pensé en limpiar la instantánea más antigua ( 1) usando rm -rf /.snapshots/1. Desafortunadamente, después de terminar, los programas esenciales /usrdesaparecieron y mi sistema no pudo iniciarse.
Entonces mi pregunta es: ¿Es ese el comportamiento esperado o hice algo mal? Si hice algo mal, ¿cuál es el procedimiento correcto para eliminar instantáneas antiguas?
Respuesta1
Parece que los problemas observados después de la eliminación /.snapshots/1no son tanto una característica de BtrFS en sí misma, sino una característica (¿mala?) de SUSE Linux:
No recuerdo cuál era el sistema de archivos raíz, pero en un sistema SLES 15.0 comparable noté que la instantánea 1estaba montada como sistema de archivos raíz (por cualquier 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)
Esa subvol=/@/.snapshots/1/snapshot)parece ser la causa fundamental.