El hilo del laberinto (Publicaciones sobre ZFS)

Problema activando una característica opcional de ZFS y actualización urgente del módulo ZFS de este servidor Linux

Jesús Cea Avión — Thu, 29 Aug 2024 00:48:00 GMT

Nota

Estas son notas rápidas durante la investigación y solución de un problema, no un artículo depurado y organizado.

He activado algunas características opcionales de uno de mis servidores con OpenZFS (una máquina con Linux) y me encuentro que la actividad del disco duro es muy baja y me salen errores de este estilo en dmesg:

[19937.978681] INFO: task z_upgrade:720856 blocked for more than 483 seconds.
[19938.004576]       Tainted: P           O      5.4.0-181-generic #201-Ubuntu
[19938.030512] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[19938.081727] z_upgrade       D    0 720856      2 0x80004000
[19938.081730] Call Trace:
[19938.081739]  __schedule+0x2e3/0x740
[19938.081744]  ? __wake_up_common_lock+0x8a/0xc0
[19938.081746]  schedule+0x42/0xb0
[19938.081747]  io_schedule+0x16/0x40
[19938.081757]  cv_wait_common+0xdc/0x180 [spl]
[19938.081759]  ? __wake_up_pollfree+0x40/0x40
[19938.081763]  __cv_wait_io+0x18/0x20 [spl]
[19938.081845]  txg_wait_synced_impl+0xd7/0x120 [zfs]
[19938.081903]  txg_wait_synced+0x10/0x40 [zfs]
[19938.081945]  dmu_objset_id_quota_upgrade_cb+0xba/0x170 [zfs]
[19938.081986]  dmu_objset_upgrade_task_cb+0xdf/0x100 [zfs]
[19938.081992]  taskq_thread+0x245/0x430 [spl]
[19938.081994]  ? wake_up_q+0xa0/0xa0
[19938.081998]  kthread+0x104/0x140
[19938.082003]  ? task_done+0x90/0x90 [spl]
[19938.082005]  ? kthread_park+0x90/0x90
[19938.082007]  ret_from_fork+0x35/0x40

Un top muestra una carga muy elevada en arc_prune, 99.4 de sys time.

El smartctl o leer el disco duro entero con ddrescue, no muestran ningún error. Esto parece un bug de OpenZFS.

Si importo el zpool en read only, funciona. Esto me permitiría recuperar los datos en caso necesario. No estoy en situación catastrófica aún, aunque no puedo hacer más copias de seguridad en este disco duro [1].

[1]

Este servidor Linux es mi servidor de copias de seguridad. Si se perdiese ese zpool, se perdería la copia de los datos, no los datos originales. Además, ese zpool es un espejo y su otra mitad está desconectada y en otro domicilio, como procedimiento de seguridad. A las malas, tendría esa mitad actualizada hasta unas semanas antes.

Intento compilar OpenZFS 2.2.4, pero falla en construir los paquetes Debian.

Pruebo con OpenZFS 2.1.12. Toco configure para que use el Python3.8 del sistema operativo en vez del moderno 3.12.

Opto por usar el repositorio https://launchpad.net/~jonathonf/+archive/ubuntu/zfs?field.series_filter=focal , que me instalará OpenZFS 2.1.6.

Con esta versión, la cosa tiene buena pinta. Al importar el zpool, se empieza a actualizar, pero es un proceso que no se va de madre. Supongo que la actualización costosa es debido a la activación de project_quota.

La cuestión es no hacer más upgrades con esta versión de OpenZFS, de momento, para poder volver atrás si es necesario.

Actualización de características en un sistema de ficheros ZFS (20230515)

Jesús Cea Avión — Sun, 28 May 2023 13:36:00 GMT

Este artículo es una continuación de Actualización de características en un sistema de ficheros ZFS (20200528). Lee primero ese texto para saber de qué estoy hablando.

Con el paso del tiempo voy actualizando ZFS y es posible activar características opcionales adicionales. Desde la actualización de 2020 hay novedades:

encryption
project_quota
device_removal
obsolete_counts
zpool_checkpoint
spacemap_v2
allocation_classes
resilver_defer
bookmark_v2

¿Qué hemos activado realmente?

ZFS está bastante bien documentado. Por ejemplo, podemos ver el manual de zpool-features. También podemos ver la web oficial de OpenZFS.

Leer más… (quedan 4 minutos de lectura)

Cómo cambiar el tamaño del espacio de intercambio (SWAP) en SmartOS

Jesús Cea Avión — Wed, 11 Jan 2023 23:54:00 GMT

Nota

En este documento voy a usar los términos SWAP y espacio de intercambio de forma indistinta.

Cuando se realiza una instalación nueva, SmartOS crea un dataset de SWAP del mismo tamaño que la memoria RAM del ordenador. Esto puede ser apropiado para máquinas grandes, pero cuando vamos escasos de memoria un SWAP tan pequeño es problemático porque bajo Illumos (Solaris) no existe el concepto de overcommit de memoria como en Linux. Es decir, un kernel Illumos limita el espacio de direccionamiento disponible para los programas a la suma de la memoria RAM y el espacio de intercambio (SWAP).

Por tanto, en SmartOS es común ampliar el espacio de intercambio.

Una de mis máquinas tiene solo 8GB de RAM y veo lo siguiente:

[root@X ~]# swap -s
total: 3928724k bytes allocated + 221992k reserved = 4150716k used, 8223728k available

[root@X ~]# zfs get all zones/swap
NAME        PROPERTY              VALUE                    SOURCE
zones/swap  type                  volume                   -
zones/swap  creation              vie. dic.  2  8:38 2022  -
zones/swap  used                  8,22G                    -
zones/swap  available             614G                     -
zones/swap  referenced            3,71G                    -
zones/swap  compressratio         2.18x                    -
zones/swap  reservation           none                     default
zones/swap  volsize               7,97G                    local
zones/swap  volblocksize          8K                       default
zones/swap  checksum              on                       default
zones/swap  compression           lz4                      inherited from zones
zones/swap  readonly              off                      default
zones/swap  createtxg             92                       -
zones/swap  copies                1                        default
zones/swap  refreservation        8,22G                    local
zones/swap  guid                  1242262060458694733      -
zones/swap  primarycache          all                      default
zones/swap  secondarycache        all                      default
zones/swap  usedbysnapshots       0                        -
zones/swap  usedbydataset         3,71G                    -
zones/swap  usedbychildren        0                        -
zones/swap  usedbyrefreservation  4,52G                    -
zones/swap  logbias               latency                  default
zones/swap  dedup                 off                      default
zones/swap  mlslabel              none                     default
zones/swap  sync                  standard                 default
zones/swap  refcompressratio      2.18x                    -
zones/swap  written               3,71G                    -
zones/swap  logicalused           8,01G                    -
zones/swap  logicalreferenced     8,01G                    -
zones/swap  snapshot_limit        none                     default
zones/swap  snapshot_count        none                     default
zones/swap  redundant_metadata    all                      default
zones/swap  encryption            off                      default
zones/swap  keylocation           none                     default
zones/swap  keyformat             none                     default
zones/swap  pbkdf2iters           0                        default

Por necesidades de servicio, requiero ampliar bastante el espacio de intercambio que, como he dicho, limita el espacio de direccionamiento total disponible para todos los programas.

Leer más… (quedan 4 minutos de lectura)

Instalación manual de Kubuntu 20.04 con LUKS y ZFS

Jesús Cea Avión — Tue, 29 Sep 2020 21:02:00 GMT

Recientemente he estado experimentando con las versiones 20.04 de Ubuntu y Kubuntu y con la versión actual de Tumbleweed, la distribución rolling release de OpenSUSE. Algunos resultados:

Kubuntu y OpenSUSE utilizan KDE, mi entorno preferido de escritorio. Ubuntu emplea Gnome, entorno que suelo probar de vez en cuando y cada vez me parece peor (para mi gusto y mis necesidades).
Ubuntu y Kubuntu soportan ambos ZFS de forma nativa. Desde que utilicé ZFS en Solaris en 2005, no quiero usar nada más. Los otros sistemas de ficheros son de juguete.

Además, mi máquina actual emplea ZFS sobre Linux y lo exprimo de forma exhaustiva: snapshots diarios, replicación, copias de seguridad rápidas, clones... No, no quiero usar otra cosa.
Kubuntu tiene un soporte de tres años para los paquetes de software propios, mientras que Ubuntu, su base, ofrece cinco años de soporte.

Esto ya lo he sufrido en mi Sistema Operativo actual, Kubuntu 16.04. Afortunadamente, la base Ubuntu de Kubuntu sí tiene cinco años de soporte.
El instalador de Ubuntu incluye un instalador ZFS experimental. El instalador de Kubuntu no.
Si haces una instalación ZFS de Ubuntu, no tienes la opción de cifrado. El cifrado solo está disponible para Sistemas de ficheros más tradicionales. Y esto a pesar de que las versiones recientes de ZFS tienen cifrado nativo y que también se podría usar LUKS (que es mi solución hasta el momento).

Descarté OpenSUSE rápidamente porque no tiene un soporte evidente de ZFS, aunque en casa hay otro ordenador con Tumbleweed y estamos contentos con la experiencia. Además, no quiero que todos los ordenadores de casa utilicen la misma rolling release, porque una actualización problemática puede ser una catástrofe.

Mi decisión ha sido la siguiente:

Leer más… (quedan 6 minutos de lectura)

Cuidado al activar "userobj_accounting" en ZFS

Jesús Cea Avión — Sat, 18 Jul 2020 21:53:00 GMT

Tras escribir Actualización de características en un sistema de ficheros ZFS (20200528) y decidir que todas mis máquinas con ZFS eran estables y no necesitaban la seguridad de poder volver a una versión previa del Sistema Operativo, me puse a actualizar mis ZPOOLs ZFS con todas las características opcionales disponibles.

La actualización fue simple, rápida e indolora salvo en uno de mis servidores. En ese servidor la operación se eternizó, con una carga de CPU muy elevada, a pesar de que la actividad de disco era relativamente baja.

De todas las características opcionales activadas, la única potencialmente costosa es userobj_accounting, porque requiere repasar los metadatos de todos los archivos y directorios en el ZPOOL.

La extrema carga de CPU en ese servidor es evidente:

top - 02:11:43 up 16 min,  1 user,  load average: 69.54, 61.05, 34.18
Tasks: 298 total,  66 running, 171 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.0 us, 99.5 sy,  0.0 ni,  0.0 id,  0.3 wa,  0.0 hi,  0.2 si,  0.0 st
KiB Mem :  1994684 total,   240660 free,  1568512 used,   185512 buff/cache
KiB Swap:        0 total,        0 free,        0 used.   279708 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
18438 root      20   0       0      0      0 R   3.6  0.0   0:00.74 arc_prune
18603 root      20   0       0      0      0 R   3.6  0.0   0:00.15 arc_prune
18630 root      20   0       0      0      0 R   3.3  0.0   0:18.67 arc_prune
18461 root      20   0       0      0      0 R   3.3  0.0   0:00.63 arc_prune
18483 root      20   0       0      0      0 R   3.3  0.0   0:00.58 arc_prune
18507 root      20   0       0      0      0 R   3.3  0.0   0:00.42 arc_prune
18522 root      20   0       0      0      0 R   3.3  0.0   0:00.37 arc_prune
18528 root      20   0       0      0      0 R   3.3  0.0   0:00.36 arc_prune
18540 root      20   0       0      0      0 R   3.3  0.0   0:00.31 arc_prune
18548 root      20   0       0      0      0 R   3.3  0.0   0:00.28 arc_prune
18552 root      20   0       0      0      0 R   3.3  0.0   0:00.26 arc_prune
18553 root      20   0       0      0      0 R   3.3  0.0   0:00.26 arc_prune
18560 root      20   0       0      0      0 R   3.3  0.0   0:00.25 arc_prune
18563 root      20   0       0      0      0 R   3.3  0.0   0:00.24 arc_prune
18581 root      20   0       0      0      0 R   3.3  0.0   0:00.16 arc_prune
18589 root      20   0       0      0      0 R   3.3  0.0   0:00.15 arc_prune
18596 root      20   0       0      0      0 R   3.3  0.0   0:00.15 arc_prune
18599 root      20   0       0      0      0 R   3.3  0.0   0:00.15 arc_prune

Aquí vemos que la carga de CPU es muy elevada, casi 70, con más de un 99% del tiempo consumido en el Sistema Operativo por hilos ejecutando arc_prune. Buscando ese nombre en internet, aparece un enlace interesante: arc_prune: high load and soft lockups #6223.

Leer más… (quedan 4 minutos de lectura)

Actualización de características en un sistema de ficheros ZFS (20200528)

Jesús Cea Avión — Thu, 28 May 2020 21:53:00 GMT

A medida que ZFS evoluciona, se van desplegando características opcionales. Para preservar la compatibilidad, estas características nuevas son opcionales, un ZPOOL ZFS que no las utilice será compatible con versiones previas de ZFS.

Activar características opcionales en un ZPOOL ZFS es una decisión que no debe tomarse a la ligera. Algunas sí, pero no todas las características opcionales pueden desactivarse una vez que se activan en un ZPOOL ZFS. Por tanto, la regla de oro es que solo hay que activar características cuando hayamos tomado la decisión irrevocable de no volver atrás en una versión determinada de ZFS.

En esta valoración hay que considerar también con atención los mecanismos de los que disponemos ante una fallo catastrófico del sistema operativo. Por ejemplo, ¿el entorno de recuperación que tenemos en el pendrive USB es capaz de importar un ZPOOL ZFS con esa característica activada?

El ciclo de vida de una característica opcional suele ser el siguiente:

Deshabilitada: La implementación ZFS soporta una característica determinada, pero no está activada en un ZPOOL ZFS dado. Esto permite importar el ZPOOL ZFS en una versión anterior de ZFS, si fuera necesario.
Habilitada: Hemos activado la característica opcional, pero aún no se está utilizando. Habitualmente el ZPOOL ZFS se podrá importar en una versión anterior de ZFS. Por lo general, se podrá desactivar la característica opcional y volver a dejarla como deshabilitada.
Activa: La característica opcional está en uso. Como regla general, el ZPOOL ZFS no se podrá importar en versiones de ZFS que no conozcan esa característica opcional. A veces es posible importar el ZPOOL ZFS en modo solo lectura, dependiendo de los detalles de funcionamiento de esa característica.

Algunas características opcionales pueden pasar de activas a habilitadas y, por tanto, se podrían deshabilitar o bien importar el ZPOOL ZFS en un versión de ZFS que no reconozca esa característica. Por ejemplo, una característica que afecte a la destrucción de un dataset puede pasar de habilitada a activa mientras se está destruyendo un dataset, pasando nuevamente a habilitada al terminar.

No obstante, como regla general, una característica que pasa a estar activa permanecerá en ese estado permanentemente. Normalmente esto se documenta en cada característica.

Vayamos al grano.

Una de mis máquinas lleva muchos meses funcionando con la misma versión del sistema operativo y de ZFS, sin ningún problema. Considero entonces que no voy a volver a una versión anterior y, por tanto, activar características opcionales parece poco arriesgado y posiblemente ventajoso.

Veamos qué nos dice el sistema operativo:

root@csi:~# zfs upgrade
This system is currently running ZFS filesystem version 5.

All filesystems are formatted with the current version.
root@csi:~# zpool upgrade
This system supports ZFS pool feature flags.

All pools are formatted using feature flags.


Some supported features are not enabled on the following pools. Once a
feature is enabled the pool may become incompatible with software
that does not support the feature. See zpool-features(5) for details.

POOL  FEATURE
---------------
blue
      multi_vdev_crash_dump
      large_dnode
      sha512
      skein
      edonr
      userobj_accounting
datos
      multi_vdev_crash_dump
      large_dnode
      sha512
      skein
      edonr
      userobj_accounting

Leer más… (quedan 2 minutos de lectura)

Notas de trabajo: Upgrading SmartOS when installed in your harddisk

Jesús Cea Avión — Mon, 20 Apr 2020 00:12:00 GMT

Advertencia

ATENCIÓN:

Este artículo transcribe mis notas sobre mi intento de actualizar el arranque personalizado en mis instalaciones SmartOS de GRUB al nuevo Loader de Illumos. Mi idea era usar estas notas para escribir un artículo en inglés describiendo el proceso, pero las cosas no fueron bien y, además, el ecosistema ha cambiado de maneras muy interesantes.

ATENCIÓN:

El procedimiento descrito aquí es un "trabajo en curso" y no funciona correctamente.

Antecedentes:

Leer más… (quedan 3 minutos de lectura)

Dumping SmartOS boot zpool when booting from harddisk

Jesús Cea Avión — Tue, 24 Sep 2019 00:19:00 GMT

Read first

Before reading this article you would find useful to become familiar with this other two:

Problem to solve

The steps described in previous articles create a SmartOS installation booting from the harddisk instead the regular boot from a CD, a DVD, a USB pendrive or PXE. This is useful when managing remote machines with no physical access. You must be careful, though, since a mistake in the manipulation of the boot zpool can leave the machine offline with a slow and painful recovery procedure.

For my personal needs (servers hosted in a remote datacenter), my approach for boot recovery would be to restart the server with the rescue mode facilities of the datacenter using an Operating system with ZFS support. That would be enough to mount the harddisk and correct any misconfiguration.

This approach is fine 99.9% of the time, but it doesn't work (easily) if there is an issue in early boot stages, like a corruption of GRUB, bad upgrading of GRUB (trying, for instance, to support features available in new ZFS releases) or if you want to upgrade to new Illumos loader, enable ZFS encryption, etc.

We need a fast way to recover the machine if something goes wrong in the early boot stage.

Since in my case the boot ZFS zpool is only 1 GB in size, what about just dumping the harddisk datablocks as a file in another server? With gigabit data speed, you can rewrite 1 GB in ten seconds. Booting in rescue mode and typing the appropriate commands would be the slow part!

Leer más… (quedan 5 minutos de lectura)

Backup doméstico seguro con Linux, cifrado y ZFS (VII): Actualización y reconfiguración del sistema

Jesús Cea Avión — Thu, 27 Dec 2018 18:23:00 GMT

Contenido

1 Pasos previos

Continuamos donde lo habíamos dejado en Backup doméstico seguro con Linux, cifrado y ZFS (VII): Cambio de tarjeta microSD y redimensionamiento LUKS/LVM/FS.

2 Actualización a Ubuntu 16.04

Veo lo siguiente al conectar a mi servidor ProLiant por SSH:

New release '16.04.5 LTS' available.
Run 'do-release-upgrade' to upgrade to it.

Leer más… (quedan 9 minutos de lectura)

Upgrading SmartOS when installed in your harddisk

Jesús Cea Avión — Tue, 25 Oct 2016 00:02:00 GMT

Advertencia

Installing SmartOS in your harddisk is a not supported configuration. Be careful and try to understand what are you doing.

SmartOS is designed to boot from USB, DVD or PXE. Nothing is installed in the harddisk, only your configuration and data. Upgrading the SmartOS hypervisor is, therefore, trivial and risk free and rollback safe.

In Installing/booting SmartOS in/from a harddisk without physical access I describe a procedure to install SmartOS in your harddisk when you have no physical access to your server. This is very important to me because I want to run SmartOS on hosted servers that I have never actually seen in real life.

To upgrade SmartOS using this configuration you can do this:

Leer más… (quedan 4 minutos de lectura)