Si has llegado hasta aquí probablemente sea porque instalaste Ubuntu 20.04 y marcaste alguna opción habilitando el soporte para ZFS. Probablemente, al igual que yo, pensasteis que no habría muchas diferencias y que bueno, probar cosas nuevas no vendría nada mal. Sin embargo, para mí ha sido un error de manual.
Estoy bastante acostumbrado a saber qué particiones tengo en el disco duro, cuál de ellas tiene el boot instalado para la BIOS UEFI, etc… Y bastante habituado también a ver el gparted con una ristra interminable de particiones, que, aunque podría parecer complejo, al final es el método que conoces y al que te has habituado a utilizar. Sin embargo, al habilitar el ZFS todo esto cambió.
Esta partición es el pool único para ZFS. No estoy capacitado todavía para explicar por qué esto funciona así y no de otra forma, pero el caso es que con gparted no puedes ir más allá. No puedes empequeñecer la partición para instalar otra distro con EXT4, o BTRFS… No, tu disco ahora es «propiedad» del pool ZFS.
Y bueno, el caso es que al ser un ordenador instalado desde cero no ha habido grandes problemas hasta que… viendo el log de instalación de APT sale un bonito mensaje avisando de que el zpool está lleno y que no va a crear otra snapshot.
En este momento me asaltan muuuchas preguntas. ¿¿Lleno?? ¿¿De qué?? ¡¡Pero si no tengo tanto usado!! Y sobre las snapshots más aún. ¿¿Qué son?? ¿¿Para qué están ahí y por qué se crean sin mi permiso?? ¿¿Por qué están ocupando espacio??
Ojalá pudiera responder a todas esas preguntas, sin embargo, lo que voy a intentar resolver en este tutorial es el problema del espacio en disco. El comando básico que usaré por ahora es ZFS List. Esto debería mostrar los volúmenes que se han creado, que actúan a modo de particiones «lógicas»
zfs list
Pero para mi sorpresa, en lugar de ver una corta lista con un par, o a lo sumo tres particiones, me encuentro con centenares de ellas creadas y haciendo imposible entender la salida del comando ZFS.
Algo así como una ruta rpool/ROOT/ubuntu_user/var/lib/sha256_hash. Todo muy extraño, la verdad. Navegando un poco y viendo de dónde venía parece que todo tiene que ver con docker. La configuración por defecto se salta el sistema de ficheros habitual (tal y como pasaría en una instalación «normal» de docker en Ubuntu) y crea un pool nuevo para cada una de las capas de las imágenes de docker creadas. Una auténtica aberración que para mí complica las cosas mucho más de lo esperado.
En mi caso, lo que he hecho, ya que no necesito más las imágenes de docker ha sido borrarlo todo y dejar ese espacio libre. Si necesitas cambiar la configuración de docker a una que se adapte más a lo que busques probablemente puedas encontrar alguna cosa de esas en la documentación oficial del driver ZFS para docker.
Vamos a borrar los contenedores parados e imágenes sueltas con el comando
docker system prune
Y puede ser que aún así nos toque borrar manualmente alguna imagen más. Mostramos todas las imágenes con
docker images
Y las borramos una a una con el comando
docker rmi <id de imagen> [<más ids de imágenes>… ]
¿Y ya hemos acabado? No… Nos queda una última cosa: Liberar el espacio sobrante de las snapshots que se crearon automáticamente. Es un poco complejo, así que usaremos esta herramienta: zfs-prune-snapshots. La descargamos y nos vamos a una carpeta para usarla. El uso no puede ser más sencillo:
sudo ./zfs-prune-snapshots 1s
Para borrar todas las snapshots más antiguas a 1 segundo. Con esto y un reinicio deberíamos tener más limpio nuestro pool de imágenes ZFS. Lo podemos comprobar haciendo un zfs list de nuevo.
Pasos extra
Es posible que a pesar de haber seguido toda esta guía todavía te queden muchos volúmenes (o snapshots, o como se llamen) sueltos. Buscando un poco más he encontrado una opción alternativa, aunque aviso, suena a que es algo bastante peligroso y podrías cargarte algo importante. Si lo haces, es bajo tu propia responsabilidad. Yo sólo digo que en mi sistema y bajo ciertas circunstancias me ha funcionado.
Este comando tiene dos partes. La primera, extrae una lista de snapshots del pool de ZFS. La segunda parte, separada por un caracter | se encarga de borrarlos. Si miráis bien, veréis una n dentro de los argumentos del zfs destroy. Esto lo que hace es decirte qué va a hacer sin hacerlo realmente (dry run, como se dice en la jerga). Es útil para detectar alguna anomalía antes de haber metido la pata hasta el fondo. Cuando ya estés seguro, simplemente borra la n de ahí y lo eliminará. No lo pongo para que no copies y pegues sin leer.
sudo zfs list -t snapshot -o name | sudo xargs -n 1 zfs destroy -vnR
Ahora si hacemos por última vez un zfs list veremos una importante diferencia, la verdad…
Un saludo!
