Primeras impresiones de Ubuntu 20.04 Focal Fossa y OpenZFS

per Victor Carceler — darrera modificació 2021-01-07T09:27:30+01:00

Recientemente se ha publicado la versión 20.04 de Ubuntu que tiene por nombre Focal Fossa. Se trata de una versión LTS con 5 años de soporte y será la versión que utilizaremos en los ordenadores del centro a partir del próximo curso.

Como siempre cada nueva versión de una distribución aporta nuevas versiones de las aplicaciones y algunas novedades interesantes.

Algunas de las novedades más relevantes de la versión 20.04 son:

  • El escritorio Gnome va mucho más fluido.
  • Se puede realizar la instalación sobre OpenZFS aunque se trate de una característica experimental.
  • La versión de servidor abandona el instalador de Debian y hay que utilizar un nuevo sistema para las instalaciones desatendidas.
  • Está disponible virtio-fs para compartir ficheros entre el host y las máquinas virtuales de manera eficiente.
  • Está disponible WireGuard.

Y por supuesto versiones nuevas de todos los programas y mejoras estéticas. Son demasiados cambios para comentar en un solo artículo así que aquí únicamente voy a hacer un pequeño comentario sobre OpenZFS.

https://commons.wikimedia.org/wiki/File:Openzfs.svgUbuntu 20.04 sobre OpenZFS

Ubuntu soporta OpenZFS desde hace varias versiones. Nosotros ya lo utilizábamos en el centro en producción con la versión 16.04 LTS para gestionar el almacenamiento de libvirt/KVM en el servidor del centro. La versión actual de ese servidor es Edoras y allí también se está utilizando OpenZFS, con Ubuntu 18.04 LTS, para gestionar el almacenamiento de las máquinas virtuales y replicar los snapshots a otra máquina.

Pero hay una diferencia muy importante entre utilizar OpenZFS para gestionar un pool de discos con datos para alguna aplicación (como libvirt/KVM) y tener el sistema instalado sobre OpenZFS. Ninguno de los casos mencionados utiliza OpenZFS para el sistema.

Desde que es posible ejecutar OpenZFS en GNU/Linux ha habido hacks para instalar el sistema sobre OpenZFS pero han sido soluciones, por decirlo suavemente, poco prácticas.

Otros sistemas operativos como FreeBSD han disfrutado de una mayor integración con ZFS desde hace mucho tiempo. Así no resulta extraño instalar el sistema sobre ZFS obteniendo todas sus ventajas también para el propio sistema operativo. Abriendo las puertas, entre otras cosas, a disfrutar de snapshots tomados de manera automática al instalar software o al realizar cambios de configuración.

Bien, pues esta situación se está acercando a GNU/Linux o por lo menos lo está haciendo en la distribución Ubuntu. En la versión 19.10 (que no es LTS) se introdujo la instalación experimental sobre OpenZFS y se añadió la integración con zsys, un demonio para gestionar la integración del sistema con ZFS.

En la versión 20.04 se puede realizar, todavía de manera experimental, la instalación del sistema sobre ZFS y de ser así zsys realiza snapshots de manera automática cuando se instala software gestionando automáticamente el gestor de arranque para permitir revertir el estado del sistema a cualquiera de los snapshots disponibles.

Rendimiento

Es cierto que ZFS brilla especialmente cuando se utiliza para gestionar un pool de varios dispositivos de almacenamiento. En un ordenador personal normalmente hay un solo disco duro así es que se podría pensar que ZFS no es necesario, pero entonces nos estaríamos olvidando de:

  • La integridad de los datos.
  • La cache ARC.
  • La capacidad de realizar snapshots y replicarlos.
  • La posibilidad de crear datasets (el equivalente a un sistema de ficheros) como quien crea directorios.
  • Gracias a la integración de zsys la posiblidad de revertir el sistema a un estado previo desde el gestor de arranque.
  • La posibilidad de clonar contenedores LXD de manera inmediata.
  • La compresión y el cifrado transparentes (ambos opcionales).

Entre otras cosas.

¿Pero qué hay del rendimiento? ¿No será un sistema de archivos tan complejo que tendrá un rendimiento pésimo?

Para desvelar esta cuestión lo mejor es acudir a la prueba más exigente para cualquier dispositivo de almacenamiento: un test de escrituras aleatorias síncronas.

En nuestro caso:

fio --name=random-write --ioengine=posixaio --rw=randwrite --bs=64k --size=256m --numjobs=16 --iodepth=16 --runtime=60 --time_based --fsync=1 --end_fsync=1 --group_reporting

Recientemente realicé este test en el portátil en el que trabajo (un HP 250 G6 con un disco M.2 Micron MTFDDAV256TBN-1A de 256GB) para el artículo: "Notas sobre el rendimiento de disco". Y explicaba que con cualquier otro tipo de carga (sobre todo con lecturas secuenciales) se obtendría un rendimiento mejor que todavía aumentará, y mucho, al utilizar la RAM de la máquina como cache.

En dicho artículo el portátil con Ubuntu 18.04 sobre EXT4 obtenía una velocidad de escritura de 131MiB/s con 2102 IOPS.

Pues bien, el mismo portátil con Ubuntu 20.04 instalado sobre OpenZFS con la configuración por defecto obtiene:

usuario@laika:~/test$ time fio --name=random-write --ioengine=posixaio --rw=randwrite --bs=64k --size=256m --numjobs=16 --iodepth=16 --runtime=60 --time_based --fsync=1 --end_fsync=1 --group_reporting
random-write: (g=0): rw=randwrite, bs=(R) 64.0KiB-64.0KiB, (W) 64.0KiB-64.0KiB, (T) 64.0KiB-64.0KiB, ioengine=posixaio, iodepth=16
...
fio-3.16
Starting 16 processes
random-write: Laying out IO file (1 file / 256MiB)
random-write: Laying out IO file (1 file / 256MiB)
random-write: Laying out IO file (1 file / 256MiB)
random-write: Laying out IO file (1 file / 256MiB)
random-write: Laying out IO file (1 file / 256MiB)
random-write: Laying out IO file (1 file / 256MiB)
random-write: Laying out IO file (1 file / 256MiB)
random-write: Laying out IO file (1 file / 256MiB)
random-write: Laying out IO file (1 file / 256MiB)
random-write: Laying out IO file (1 file / 256MiB)
random-write: Laying out IO file (1 file / 256MiB)
random-write: Laying out IO file (1 file / 256MiB)
random-write: Laying out IO file (1 file / 256MiB)
random-write: Laying out IO file (1 file / 256MiB)
random-write: Laying out IO file (1 file / 256MiB)
random-write: Laying out IO file (1 file / 256MiB)
Jobs: 16 (f=16): [w(16)][100.0%][w=144MiB/s][w=2298 IOPS][eta 00m:00s]
random-write: (groupid=0, jobs=16): err= 0: pid=27642: Thu May  7 19:48:54 2020
  write: IOPS=2562, BW=160MiB/s (168MB/s)(9621MiB/60060msec); 0 zone resets
    slat (nsec): min=1481, max=27794k, avg=16063.84, stdev=205415.43
    clat (usec): min=75, max=314684, avg=13715.49, stdev=18016.91
     lat (usec): min=80, max=319342, avg=13731.55, stdev=18025.48
    clat percentiles (usec):
     |  1.00th=[   955],  5.00th=[  1369], 10.00th=[  1795], 20.00th=[  3261],
     | 30.00th=[  4883], 40.00th=[  6521], 50.00th=[  8356], 60.00th=[ 10552],
     | 70.00th=[ 13566], 80.00th=[ 18482], 90.00th=[ 29492], 95.00th=[ 45876],
     | 99.00th=[ 96994], 99.50th=[112722], 99.90th=[154141], 99.95th=[191890],
     | 99.99th=[254804]
   bw (  KiB/s): min=35650, max=336332, per=99.81%, avg=163721.65, stdev=3352.15, samples=1920
   iops        : min=  555, max= 5254, avg=2555.52, stdev=52.41, samples=1920
  lat (usec)   : 100=0.01%, 250=0.04%, 500=0.05%, 750=0.19%, 1000=0.97%
  lat (msec)   : 2=10.34%, 4=12.87%, 10=33.44%, 20=24.14%, 50=13.65%
  lat (msec)   : 100=3.40%, 250=0.88%, 500=0.02%
  fsync/fdatasync/sync_file_range:
    sync (usec): min=51, max=521551, avg=85223.81, stdev=44242.59
    sync percentiles (msec):
     |  1.00th=[   19],  5.00th=[   30], 10.00th=[   37], 20.00th=[   52],
     | 30.00th=[   65], 40.00th=[   73], 50.00th=[   81], 60.00th=[   89],
     | 70.00th=[   97], 80.00th=[  108], 90.00th=[  128], 95.00th=[  165],
     | 99.00th=[  257], 99.50th=[  284], 99.90th=[  321], 99.95th=[  430],
     | 99.99th=[  518]
  cpu          : usr=0.34%, sys=0.09%, ctx=121198, majf=9, minf=844
  IO depths    : 1=4.7%, 2=9.9%, 4=23.3%, 8=109.8%, 16=53.3%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=94.7%, 8=0.5%, 16=4.9%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,153929,0,155333 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=16

Run status group 0 (all jobs):
  WRITE: bw=160MiB/s (168MB/s), 160MiB/s-160MiB/s (168MB/s-168MB/s), io=9621MiB (10.1GB), run=60060-60060msec

real	1m0,807s
user	0m4,079s
sys	0m25,827s
usuario@laika:~/test$

Lo que desmiente de manera contundente cualquier sombra de duda sobre el rendimiento de OpenZFS.

Es cierto que este rendimiento espectacular se debe en parte a la compresión transparente con LZ4 que está activada por defecto. Las escrituras generadas por fio tienen cierta redundancia, lo que permite que al comprimirse ocupen menos y sea necesario escribir menos datos en disco.

Efectivamente es una trampa porque el dispositivo de almacenamiento no ha incrementado su velocidad. Pero activar la compresión transparente en OpenZFS no tiene ninguna contrapartida y el ratio de compresión de los datos de fio es similar al que suelo observar en las imágenes KVM del servidor, así que sigue resultando un test representativo de una carga de trabajo habitual.

Por supuesto otros datos como los log del sistema se comprimen muchísimo mejor y proporcionan ratios de compresión más altos.

Y en el caso de que los datos no obtengan un ratio mínimo al comprimirse OpenZFS deja de manera dinámica de comprimir esos datos para no consumir CPU de manera ineficiente.

Esquema de particiones y pools

Cuando no es necesario arrancar el sistema siempre se recomienda utilizar discos enteros como miembros del pool ZFS. Sin embargo los detalles necesarios para el arranque imponen el uso de una partición EFI system partition y para utilizar el espacio swap también se opta por utilizar una partición propia.

Los detalles del proceso de arranque imponen requisitos al pool en el que se mantiene /boot así que el instalador opta por crear dos particiones en el espacio restante: una pequeña (de 2GiB) para crear el pool que contendrá el dataset para /boot y otra con todo el espacio restante para el pool del que tomarán espacio el resto de datasets utilizados por el sistema o los datos de los usuarios.

usuario@laika:~$ lsblk /dev/sda
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 238,5G  0 disk 
├─sda1   8:1    0   512M  0 part /boot/efi
├─sda2   8:2    0     2G  0 part [SWAP]
├─sda3   8:3    0     2G  0 part 
└─sda4   8:4    0   234G  0 part 
usuario@laika:~$

Los pools definidos son:

root@laika:/home/usuario# zpool list
NAME    SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
bpool  1,88G   181M  1,70G        -         -     0%     9%  1.00x    ONLINE  -
rpool   232G  12,4G   220G        -         -     6%     5%  1.00x    ONLINE  -
root@laika:/home/usuario#

El nombre de los pools hace refenencia a su función: boot pool (bpool) y root pool (rpool). Y se puede comprobar que se crearon con una configuración diferente:

Para bpool:

root@laika:/home/usuario# zpool history bpool
History for 'bpool':
2020-05-07.12:43:23 zpool create -f -o ashift=12 -d -o feature@async_destroy=enabled -o feature@bookmarks=enabled -o feature@embedded_data=enabled -o feature@empty_bpobj=enabled -o feature@enabled_txg=enabled -o feature@extensible_dataset=enabled -o feature@filesystem_limits=enabled -o feature@hole_birth=enabled -o feature@large_blocks=enabled -o feature@lz4_compress=enabled -o feature@spacemap_histogram=enabled -O compression=lz4 -O acltype=posixacl -O xattr=sa -O relatime=on -O normalization=formD -O canmount=off -O devices=off -O mountpoint=/boot -R /target bpool /dev/sda3
2020-05-07.12:43:23 zfs create bpool/BOOT -o canmount=off -o mountpoint=none
2020-05-07.12:43:28 zfs create bpool/BOOT/ubuntu_hrsnga -o mountpoint=/boot
2020-05-07.12:47:00 zpool set cachefile= bpool
2020-05-07.12:51:38 zpool export -a
2020-05-07.12:52:37 zpool import -c /etc/zfs/zpool.cache -aN
2020-05-07.12:55:41 zpool import -c /etc/zfs/zpool.cache -aN
2020-05-07.13:32:19 zpool import -c /etc/zfs/zpool.cache -aN
2020-05-07.14:13:17 zpool import -c /etc/zfs/zpool.cache -aN
2020-05-07.18:11:56 zpool import -c /etc/zfs/zpool.cache -aN
2020-05-08.07:24:18 zpool import -c /etc/zfs/zpool.cache -aN

root@laika:/home/usuario#

Y para rpool:

root@laika:/home/usuario# zpool history rpool
History for 'rpool':
2020-05-07.12:43:23 zpool create -f -o ashift=12 -O compression=lz4 -O acltype=posixacl -O xattr=sa -O relatime=on -O normalization=formD -O mountpoint=/ -O canmount=off -O dnodesize=auto -O sync=disabled -O mountpoint=/ -R /target rpool /dev/sda4
2020-05-07.12:43:23 zfs create rpool/ROOT -o canmount=off -o mountpoint=none
2020-05-07.12:43:23 zfs create rpool/ROOT/ubuntu_hrsnga -o mountpoint=/
2020-05-07.12:43:23 zfs create rpool/ROOT/ubuntu_hrsnga/var -o canmount=off
2020-05-07.12:43:23 zfs create rpool/ROOT/ubuntu_hrsnga/var/lib
2020-05-07.12:43:23 zfs create rpool/ROOT/ubuntu_hrsnga/var/lib/AccountsService
2020-05-07.12:43:24 zfs create rpool/ROOT/ubuntu_hrsnga/var/lib/apt
2020-05-07.12:43:24 zfs create rpool/ROOT/ubuntu_hrsnga/var/lib/dpkg
2020-05-07.12:43:24 zfs create rpool/ROOT/ubuntu_hrsnga/var/lib/NetworkManager
2020-05-07.12:43:24 zfs create rpool/ROOT/ubuntu_hrsnga/srv
2020-05-07.12:43:24 zfs create rpool/ROOT/ubuntu_hrsnga/usr -o canmount=off
2020-05-07.12:43:24 zfs create rpool/ROOT/ubuntu_hrsnga/usr/local
2020-05-07.12:43:24 zfs create rpool/ROOT/ubuntu_hrsnga/var/games
2020-05-07.12:43:24 zfs create rpool/ROOT/ubuntu_hrsnga/var/log
2020-05-07.12:43:24 zfs create rpool/ROOT/ubuntu_hrsnga/var/mail
2020-05-07.12:43:24 zfs create rpool/ROOT/ubuntu_hrsnga/var/snap
2020-05-07.12:43:24 zfs create rpool/ROOT/ubuntu_hrsnga/var/spool
2020-05-07.12:43:24 zfs create rpool/ROOT/ubuntu_hrsnga/var/www
2020-05-07.12:43:24 zfs create rpool/USERDATA -o canmount=off -o mountpoint=/
2020-05-07.12:43:24 zfs set com.ubuntu.zsys:bootfs=yes rpool/ROOT/ubuntu_hrsnga
2020-05-07.12:43:24 zfs set com.ubuntu.zsys:last-used=1588848204 rpool/ROOT/ubuntu_hrsnga
2020-05-07.12:43:24 zfs set com.ubuntu.zsys:bootfs=no rpool/ROOT/ubuntu_hrsnga/srv
2020-05-07.12:43:24 zfs set com.ubuntu.zsys:bootfs=no rpool/ROOT/ubuntu_hrsnga/usr
2020-05-07.12:43:28 zfs set com.ubuntu.zsys:bootfs=no rpool/ROOT/ubuntu_hrsnga/var
2020-05-07.12:46:55 zpool set cachefile= rpool
2020-05-07.12:46:55 zfs create rpool/USERDATA/usuario_i0pjda -o canmount=on -o mountpoint=/home/usuario
2020-05-07.12:46:55 zfs set com.ubuntu.zsys:bootfs-datasets=rpool/ROOT/ubuntu_hrsnga rpool/USERDATA/usuario_i0pjda
2020-05-07.12:46:55 zfs create rpool/USERDATA/root_i0pjda -o canmount=on -o mountpoint=/root
2020-05-07.12:46:55 zfs set com.ubuntu.zsys:bootfs-datasets=rpool/ROOT/ubuntu_hrsnga rpool/USERDATA/root_i0pjda
2020-05-07.12:46:58 zfs set sync=standard rpool
2020-05-07.12:51:38 zpool export -a
2020-05-07.12:52:32 zpool import -N rpool
2020-05-07.12:55:35 zpool import -N rpool
2020-05-07.13:32:14 zpool import -N rpool
2020-05-07.14:13:12 zpool import -N rpool
2020-05-07.18:11:51 zpool import -N rpool
2020-05-08.07:24:13 zpool import -N rpool

root@laika:/home/usuario#

Datasets utilizados

Conviene recordar que cuando se utiliza ZFS los dispositivos de almacenamiento se agrupan en un pool con una determinada configuración para conseguir cierta capacidad, tolerancia a fallos y rendimiento. Después se pueden definir datasets que pertenecen a un pool en el que consumen espacio de almacenamiento.

Los datasets de ZFS son el equivalente a los sistemas de archivos que se crean en dispositivos de bloques y se montan en un punto de montaje. Pero su creación y manipulación resulta mucho más flexible y ligera. Crear un dataset es tan rápido como crear un directorio y permite tratar a esos datos de manera diferenciada al hacer un snapshot o utilizar una configuración particular.

Así es posible crear un dataset para cada conjunto lógico de datos sin fragmentar la capacidad de almacenamiento.

La instalación de Ubuntu 20.04 LTS ha definido los siguitenes datasets:

root@laika:/boot# zfs list
NAME                                               USED  AVAIL     REFER  MOUNTPOINT
bpool                                              181M  1,57G       96K  /boot
bpool/BOOT                                         180M  1,57G       96K  none
bpool/BOOT/ubuntu_hrsnga                           180M  1,57G      180M  /boot
rpool                                             12,4G   212G       96K  /
rpool/ROOT                                        4,16G   212G       96K  none
rpool/ROOT/ubuntu_hrsnga                          4,16G   212G     2,99G  /
rpool/ROOT/ubuntu_hrsnga/srv                        96K   212G       96K  /srv
rpool/ROOT/ubuntu_hrsnga/usr                       368K   212G       96K  /usr
rpool/ROOT/ubuntu_hrsnga/usr/local                 272K   212G      144K  /usr/local
rpool/ROOT/ubuntu_hrsnga/var                       865M   212G       96K  /var
rpool/ROOT/ubuntu_hrsnga/var/games                  96K   212G       96K  /var/games
rpool/ROOT/ubuntu_hrsnga/var/lib                   853M   212G      745M  /var/lib
rpool/ROOT/ubuntu_hrsnga/var/lib/AccountsService   232K   212G      104K  /var/lib/AccountsService
rpool/ROOT/ubuntu_hrsnga/var/lib/NetworkManager    364K   212G      148K  /var/lib/NetworkManager
rpool/ROOT/ubuntu_hrsnga/var/lib/apt              61,0M   212G     56,0M  /var/lib/apt
rpool/ROOT/ubuntu_hrsnga/var/lib/dpkg             43,8M   212G     35,1M  /var/lib/dpkg
rpool/ROOT/ubuntu_hrsnga/var/log                  11,0M   212G     6,14M  /var/log
rpool/ROOT/ubuntu_hrsnga/var/mail                   96K   212G       96K  /var/mail
rpool/ROOT/ubuntu_hrsnga/var/snap                  200K   212G      120K  /var/snap
rpool/ROOT/ubuntu_hrsnga/var/spool                 232K   212G      120K  /var/spool
rpool/ROOT/ubuntu_hrsnga/var/www                    96K   212G       96K  /var/www
rpool/USERDATA                                    8,25G   212G       96K  /
rpool/USERDATA/root_i0pjda                         244K   212G      124K  /root
rpool/USERDATA/usuario_i0pjda                     8,25G   212G     4,15G  /home/usuario
root@laika:/boot#

Conviene apreciar:

  • Que existen dos pools: bpool y rpool. Cada dataset pertenece a un pool y por tanto tiene el mismo espacio disponible que existe en el pool. Cada dataset consume la cantidad de espacio que necesita.
  • Se han definido los datasets bpool/BOOT, rpool/ROOT y rpool/USERDATApara agrupar a los datasets relacionados con el arranque, la raíz del sistema y los datos del usuario. Por supuesto nosotros podremos definir nuevos datasets para nuestras aplicaciones. Por ejemplo: rpool/libvirt.
  • Se ha creeado el identificador hrsnga que aparece como sufijo de varios datasets relacionados con la raíz y el arranque.
  • Cada usuario tiene su directorio home en un dataset particular. Se ha creado el identificador i0pjda que aparece como sufijo de los datasets dedicados a los usuarios root y usuario.

Snapshots automáticos

A partir de un dataset es posible construir un snapshot que es una versión inmutable del dataset. Los snapshots pueden servir para acceder a sus contenidos (lecturas), para replicarlos y para hacer rollback y restaurar el dataset al estado en el que se encontraba cuando se hizo el snapshot. Los snapshots también pueden ser promovidos a clones y entonces permiten lecturas y escrituras.

Bien, pues zsys que se encarga de integrar el sistema con ZFS ofrece el comando zsysctl que permite automatizar varias tareas.

Por ejemplo, el comando zsysctl show muestra el estado de la máquina:

usuario@laika:~$ zsysctl show
Name:           rpool/ROOT/ubuntu_hrsnga
ZSys:           true
Last Used:      current
History:        
  - Name:       rpool/ROOT/ubuntu_hrsnga@autozsys_jgduti
    Created on: 2020-05-07 13:11:36
  - Name:       rpool/ROOT/ubuntu_hrsnga@autozsys_vilhf5
    Created on: 2020-05-07 13:11:03
  - Name:       rpool/ROOT/ubuntu_hrsnga@autozsys_ty866o
    Created on: 2020-05-07 12:54:05
  - Name:       rpool/ROOT/ubuntu_hrsnga@autozsys_t0an3y
    Created on: 2020-05-07 12:54:05
Users:
  - Name:    root
    History: 
     - rpool/USERDATA/root_i0pjda@autozsys_jgduti (2020-05-07 13:11:36)
     - rpool/USERDATA/root_i0pjda@autozsys_vilhf5 (2020-05-07 13:11:04)
     - rpool/USERDATA/root_i0pjda@autozsys_ty866o (2020-05-07 12:54:05)
     - rpool/USERDATA/root_i0pjda@autozsys_t0an3y (2020-05-07 12:54:05)
  - Name:    usuario
    History: 
     - rpool/USERDATA/usuario_i0pjda@autozsys_qwh3o6 (2020-05-08 11:15:37)
     - rpool/USERDATA/usuario_i0pjda@autozsys_d2rnhh (2020-05-08 09:30:20)
     - rpool/USERDATA/usuario_i0pjda@autozsys_phak41 (2020-05-08 08:26:11)
     - rpool/USERDATA/usuario_i0pjda@autozsys_9kls5z (2020-05-08 07:25:20)
     - rpool/USERDATA/usuario_i0pjda@autozsys_fmv9lx (2020-05-07 19:13:50)
     - rpool/USERDATA/usuario_i0pjda@autozsys_lu53r5 (2020-05-07 18:12:59)
     - rpool/USERDATA/usuario_i0pjda@autozsys_4x0o7y (2020-05-07 14:14:18)
     - rpool/USERDATA/usuario_i0pjda@autozsys_x3qy7r (2020-05-07 13:33:21)
     - rpool/USERDATA/usuario_i0pjda@autozsys_jgduti (2020-05-07 13:11:36)
     - rpool/USERDATA/usuario_i0pjda@autozsys_vilhf5 (2020-05-07 13:11:04)
     - rpool/USERDATA/usuario_i0pjda@autozsys_whlzzc (2020-05-07 12:56:42)
     - rpool/USERDATA/usuario_i0pjda@autozsys_ty866o (2020-05-07 12:54:05)
     - rpool/USERDATA/usuario_i0pjda@autozsys_t0an3y (2020-05-07 12:54:05)
     - rpool/USERDATA/usuario_i0pjda@autozsys_wanjvk (2020-05-07 12:53:45)
usuario@laika:~$

Pudiéndose observar:

  • zsys ya ha creado varios snapshots de manera automática.
  • Los snapshots creados de forma automática tienen en el nombre autozsys_ y una cadena de 6 carácteres para identificarlos.
  • Se distingue entre snapshots del sistema y snapshots de los usuarios.
  • Para cada usuario hay un historial diferente de snapshots.

La integración con el gestor de arranque permite restaurar el estado de la máquina desde grub. Ahora se muestra una nueva opción History for Ubuntu 20.04 LTS.

Grub monstrando la opción de historial para los snapshots de ZFS

Que da paso a la lista de snapshots a los que se puede revertir el estado del sistema.

Grub monstrando el historial de snapshots de ZFS

La gestión automática de snapshots con zsys está controlada por:

  • /usr/lib/systemd/user/zsys-user-savestate.timer para los snapshots de los usuarios. Se crea un snapshot del home del usuario cuando el usuario lleva un minuto con la sesión abierta y después otro nuevo cada hora hasta que cierre la sesión.
  • /usr/libexec/zsys-system-autosnapshot para crear un snapshot antes de la instalación de un paquete y actualizar el menu de grub después de que esté instalado.
  • /lib/systemd/system/zsys-gc.timer para el borrado de snapshots antiguos.

Más información: