ZFS tiene fama de sistema de ficheros que no pierde datos, y se la ha ganado: suma de verificación de cada bloque, instantáneas que no cuestan casi nada, réplicas incrementales, compresión y gestor de volúmenes en una sola pieza. En Proxmox VE es la opción de almacenamiento local más usada, y en un NAS es casi la norma. Lo que no siempre se cuenta es que, en Linux, ZFS vive en una situación peculiar: es un invitado al que el anfitrión ha dicho expresamente que no piensa esperar.
Vivian Voss lo ha medido en un análisis publicado el 6 de octubre, comparando lo que pasa al actualizar el kernel en Debian y en FreeBSD. Partimos de ahí, comprobamos los datos en las fuentes originales y añadimos lo que más nos importa a quienes montamos plataformas con ZFS: cómo lo resuelven Proxmox y Ubuntu, que no son ni Debian a pelo ni FreeBSD, y qué conviene hacer en cada caso.
El 15 de enero de 2019, la lista de correo del kernel discutía un parche pequeño para Linux 5.0. Dejaba de exportar dos funciones, __kernel_fpu_begin() y __kernel_fpu_end(), con las que un módulo podía usar los registros SIMD del procesador, los que permiten operar sobre varios valores con una sola instrucción. El kernel ya no las necesitaba fuera de su propio código. Pero ZFS on Linux sí: las usaba para calcular las sumas de verificación y la paridad de RAID-Z.
Un usuario protestó en la lista. Greg Kroah-Hartman, responsable de los kernels estables, le contestó que ZFS podría ser el mejor sistema de ficheros del planeta, pero que su licencia estaba pensada para no ser compatible con Linux, y que por eso no le importaba. Christoph Hellwig fue más breve: le pidió que se cambiara a FreeBSD «en lugar de defender que se viole el copyright y las reglas de licencia de mi trabajo y el de otros».
El parche entró en Linux 5.0 en marzo de 2019. ZFS on Linux perdió el código vectorizado de sus sumas de verificación y de su paridad, y no lo recuperó hasta julio, cuando el proyecto aprendió a guardar y restaurar esos registros por su cuenta (el cambio Linux 5.0 compat: SIMD compatibility, integrado el 12 de julio de 2019).
Un año después, el 6 de enero de 2020, Linus Torvalds dejó clara la postura en el foro de Real World Technologies: «Si alguien añade un módulo del kernel como ZFS, va por su cuenta. Yo no puedo mantenerlo, y no puedo estar atado a los cambios de kernel de otros». Y unas líneas más abajo: «No uséis ZFS. Así de simple». En el mismo mensaje dijo que ZFS ya no tenía mantenimiento real detrás. Esa parte no ha envejecido bien: según el recuento de Voss, OpenZFS ha publicado 56 versiones estables desde entonces, con cinco versiones mayores, de la 2.0 a la 2.4.
El kernel Linux se distribuye bajo GPLv2. OpenZFS hereda la CDDL de Sun Microsystems. Las dos son licencias libres, pero cada una exige condiciones que la otra no cumple.
Lo que está claro lo resume la propia documentación de OpenZFS: la combinación impide distribuir OpenZFS como parte del binario del kernel, pero nada en ninguna de las dos licencias impide distribuirlo como código fuente o como módulo binario separado.
Lo que no está claro es si ese módulo binario, cargado en el kernel, forma una obra derivada. Ahí hay dos lecturas:
| Quién | Qué sostiene |
|---|---|
| Free Software Foundation (abril de 2016) | Combinar Linux y ZFS en un binario distribuido infringe la GPL |
| Software Freedom Conservancy (febrero de 2016) | Distribuir el módulo compilado junto al kernel es una violación de la GPL, y lo dijo expresamente de Canonical |
| Canonical (febrero de 2016) | Distribuir ZFS como módulo independiente cumple las dos licencias, y lo incluye en Ubuntu desde la 16.04 |
| Debian | Sigue la lectura prudente: ofrece el código fuente en contrib y el módulo se compila en la máquina del usuario |
Ningún tribunal ha resuelto la cuestión en diez años. Para quien usa ZFS en su propio servidor, el debate jurídico pesa poco; la licencia es un problema de quien distribuye. Pero tiene una consecuencia técnica muy concreta: ZFS nunca entrará en el árbol del kernel Linux, así que siempre irá un paso por detrás.
Cada versión nueva del kernel cambia interfaces internas que usan los módulos externos. OpenZFS tiene que adaptarse, probar y publicar. Hasta que lo hace, un servidor con ese kernel no puede cargar ZFS.
Voss comparó los 17 últimos kernels principales con la primera versión estable de OpenZFS cuyas notas declaran soporte para cada uno:
| Kernel | Publicado | Primera OpenZFS compatible | Días de espera |
|---|---|---|---|
| 6.6 | 30-oct-2023 | 2.2.1 | 23 |
| 6.7 | 7-ene-2024 | 2.2.3 | 46 |
| 6.8 | 10-mar-2024 | 2.2.4 | 53 |
| 6.9 | 12-may-2024 | 2.2.5 | 86 |
| 6.10 | 14-jul-2024 | 2.2.6 | 52 |
| 6.11 | 15-sep-2024 | 2.2.7 | 88 |
| 6.12 | 17-nov-2024 | 2.2.7 | 25 |
| 6.13 | 19-ene-2025 | 2.3.1 | 50 |
| 6.14 | 24-mar-2025 | 2.3.2 | 38 |
| 6.15 | 25-may-2025 | 2.2.8 | 18 |
| 6.16 | 27-jul-2025 | 2.3.4 | 29 |
| 6.17 | 28-sep-2025 | 2.3.5 | 51 |
| 6.18 | 30-nov-2025 | 2.4.0 | 18 |
| 6.19 | 8-feb-2026 | 2.4.1 | 17 |
| 7.0 | 12-abr-2026 | 2.4.2 | 30 |
| 7.1 | 14-jun-2026 | 2.4.4 | 68 |
| 7.2 | 16-ago-2026 | 2.4.4 | 5 |
Recuento de Vivian Voss a partir de las etiquetas del kernel y las notas de OpenZFS en GitHub, a 6 de octubre de 2026. Hemos comprobado las últimas filas contra las notas de publicación: OpenZFS 2.4.2 (12 de mayo) declara soporte hasta Linux 7.0, y 2.4.4 (21 de agosto) hasta la 7.2.
La mediana es de 38 días: durante algo más de cinco semanas tras un kernel típico, el kernel más nuevo y el ZFS más nuevo no encajan. El 5 de la 7.2 es engañoso: llega justo después de una espera de 68 días, porque la 2.4.4 cerró dos ventanas a la vez.
A 9 de octubre, el kernel estable es el 7.2.9 y la rama principal va por la 7.3-rc6, así que la próxima ventana se abrirá en unas semanas. La pregunta práctica no es si va a pasar, sino si tu servidor lo va a notar. Y eso depende de la plataforma.
Debian 13 ofrece zfs-dkms en la sección contrib, hoy en la versión 2.3.9, y una 2.4.4 en trixie-backports. DKMS registra el código fuente y, cada vez que se instala un paquete de kernel, compila el módulo contra sus cabeceras, en tu servidor y con el compilador que tengas instalado. Según el recuento de Voss, son casi 369.000 líneas de C y ensamblador por actualización.
En la práctica, en Debian estable el riesgo es bajo, porque el kernel de Debian 13 es el 6.12 de soporte largo (hoy 6.12.111), muy por detrás de lo que OpenZFS ya soporta. El problema aparece cuando alguien instala un kernel más nuevo desde backports o desde fuera de Debian y la versión de OpenZFS no lo soporta todavía: la compilación falla, el kernel nuevo se instala sin ZFS y, si la raíz del sistema está en ZFS, el arranque se queda a medias. Toca elegir el kernel anterior en el menú de arranque.
Dos costumbres que lo evitan: comprobar tras cada actualización que el módulo se ha compilado (dkms status debe mostrar el módulo zfs como installed para el kernel nuevo) y no instalar kernels más recientes que los que tu versión de zfs-dkms declara soportar.
Canonical aplica su lectura de la licencia y entrega el módulo ZFS ya compilado dentro de los paquetes del kernel, desde Ubuntu 16.04. No hay DKMS ni compilación en el servidor: el kernel y el módulo salen juntos de la misma construcción, probados por Canonical. A cambio, dependes del calendario y de los parches de Canonical, que no siempre coinciden con las versiones de OpenZFS.
Proxmox VE ofrece ZFS desde la versión 3.4, también como sistema de ficheros raíz, y su documentación lo dice sin rodeos: no hace falta compilar módulos a mano, todo viene empaquetado. Proxmox mantiene su propio kernel, basado en el de Ubuntu, y lo publica con el módulo ZFS ya integrado y probado. Proxmox VE 9.2, publicado el 21 de mayo de 2026, lleva el kernel 7.0 y ZFS 2.4.
Es el modelo que más se parece al de FreeBSD sin serlo: el kernel y ZFS llegan juntos en un mismo paquete, con un fabricante que responde de la combinación. Para un clúster de virtualización, esto elimina casi del todo la ventana. Lo que no elimina es la responsabilidad de no saltarse los canales: un kernel opt-in más nuevo, que Proxmox ofrece a veces antes de hacerlo predeterminado, sigue siendo una elección que conviene probar antes en un nodo.
En FreeBSD el problema no existe en esa forma. ZFS llegó con FreeBSD 7.0 en febrero de 2008, como experimental, y forma parte del sistema base desde entonces. Desde la 13.0 (abril de 2021), el código es el mismo OpenZFS que usa Linux. En FreeBSD 15.1, publicado el 16 de junio de 2026, las notas de la versión confirman OpenZFS 2.4.2, y el instalador ofrece «Auto (ZFS)» como primera opción de particionado.
La diferencia es organizativa, no de calidad del código. El kernel y ZFS se construyen y se prueban en el mismo ciclo, salen en la misma versión y se actualizan juntos con freebsd-update. No se compila nada en el servidor y no hay que esperar a que otro proyecto se ponga al día. La licencia tampoco es un obstáculo: el código CDDL convive en el árbol de FreeBSD con el BSD, y el proyecto distribuye el binario.
FreeBSD añade además los entornos de arranque de serie. freebsd-update crea uno antes de instalar, según Voss desde las versiones 12.3 y 13.1, y bectl permite volver al anterior con dos órdenes y un reinicio. La 15.1 añade a bectl la opción -E para crear un entorno vacío, sin clonar el actual. En Linux existe lo mismo con ZFSBootMenu o zectl, pero son proyectos aparte que hay que instalar y mantener por separado.
| Plataforma | Quién compila el módulo | Quién prueba kernel + ZFS | Ventana tras un kernel nuevo | Vuelta atrás |
|---|---|---|---|---|
Debian 13 + zfs-dkms | Tu servidor, con DKMS | Nadie en conjunto; tú | Solo si instalas un kernel más nuevo que el de Debian | Kernel anterior en GRUB; ZFSBootMenu aparte |
| Ubuntu | Canonical | Canonical | Absorbida por Canonical | Kernel anterior en GRUB |
| Proxmox VE | Proxmox | Proxmox | Absorbida por Proxmox | Kernel anterior; proxmox-boot-tool permite fijarlo |
| FreeBSD 15.1 | El proyecto FreeBSD | El proyecto FreeBSD | No existe | bectl, en el sistema base |
| TrueNAS 25.04+ | iXsystems | iXsystems | Absorbida por el producto | Entornos de arranque del propio producto |
TrueNAS es el caso que mejor muestra hacia dónde ha ido el mercado. Su producto nació sobre FreeBSD, pero la versión 25.04 Fangtooth (14 de abril de 2025) unificó la línea sobre Linux 6.12. La integración que FreeBSD da de serie, TrueNAS la resuelve como fabricante, controlando el kernel y el módulo a la vez.
Si tienes servidores con ZFS, la historia de la licencia se traduce en cinco decisiones operativas:
proxmox-boot-tool kernel pin mantiene el que sabes que funciona mientras pruebas el nuevo en otro nodo del clúster.zpool upgrade, piensa en la vuelta atrás. Activar las funciones nuevas de un pool lo hace ilegible para versiones anteriores de ZFS. Si tienes que arrancar con el kernel antiguo, que trae un ZFS antiguo, puede que no monte. Actualiza los pools semanas después de actualizar el sistema, no el mismo día.zfs version muestra la de las herramientas y la del módulo cargado; si no coinciden, tienes una actualización a medias pendiente de reinicio.zfs send o un Proxmox Backup Server son las que salvan el día.El análisis de Voss toma la frase de Hellwig como consejo y concluye que, para un servidor dedicado a almacenar, tiene bastante sentido. Estamos de acuerdo en el diagnóstico, con un matiz importante: la comparación justa no es FreeBSD frente a Linux, sino FreeBSD frente a la plataforma Linux concreta que vas a usar.
FreeBSD tiene la integración más limpia. Si el servidor es sobre todo almacenamiento, un NAS o un nodo de copias, y tu equipo conoce FreeBSD, la combinación de ZFS en el sistema base y entornos de arranque es difícil de mejorar. También hay paneles que lo aprovechan, como Sylve para bhyve y jails.
Debian con DKMS es la opción más frágil, y no porque el código sea peor, sino porque la integración la haces tú en cada actualización.
Ubuntu, Proxmox VE y TrueNAS han resuelto el problema como fabricantes. Absorben la ventana, entregan el kernel y el módulo probados juntos y responden de la combinación. Para virtualización, donde ZFS convive con KVM, Ceph, la red del clúster y el ecosistema de herramientas, Proxmox es la opción natural, y ZFS en Proxmox es una de las combinaciones más probadas que hay.
En Cloud Privado montamos clústeres de Proxmox con ZFS en almacenamiento local y Ceph cuando hace falta almacenamiento compartido. Si estás valorando cómo organizar el almacenamiento de tu plataforma, es una buena conversación para empezar.
Por la licencia. El kernel es GPLv2 y OpenZFS es CDDL, y la combinación impide distribuir OpenZFS como parte del binario del kernel. Por eso se distribuye como módulo aparte, compilado por la distribución (Ubuntu, Proxmox) o en la máquina del usuario (Debian, con DKMS).
Usarlo en tu propio servidor no plantea problemas. El debate es sobre distribuir el módulo compilado junto al kernel: la FSF y la Software Freedom Conservancy consideran que infringe la GPL, y Canonical sostiene que no. Ningún tribunal lo ha resuelto.
Con DKMS, la compilación del módulo falla y el kernel nuevo se queda sin ZFS. Si la raíz está en ZFS, hay que arrancar con el kernel anterior desde el menú de arranque. En Ubuntu y Proxmox no ocurre con sus kernels oficiales, porque el módulo viene ya compilado y probado.
Según el recuento de Vivian Voss sobre los 17 últimos kernels, entre 5 y 88 días, con una mediana de 38. Es un dato histórico, no una garantía para los próximos.
La 2.4.2, según las notas de la versión. FreeBSD 15.1 se publicó el 16 de junio de 2026.
No. Proxmox entrega su kernel con el módulo ZFS ya integrado. Proxmox VE 9.2 lleva el kernel 7.0 y ZFS 2.4.
bectl.-E de bectl.
Cuando una API o una web va lenta, la tentación es subir de plan: más vCPU, más RAM, discos más rápidos. Antes conviene saber qué está frenando de verdad al servidor. Repasamos las seis señales que lo delatan (CPU, memoria, disco, red, límites y latencia de la aplicación), con los comandos para medirlas, cómo leerlos sin engañarse y lo que hemos comprobado en Debian y Ubuntu.
OpenSSH no lo escribió una sola persona. Viene del SSH que Tatu Ylönen publicó en 1995, de la versión libre que rescató Björn Grönvall y de un esprint de dos meses de media docena de desarrolladores de OpenBSD. Contamos quién hizo qué, con fechas comprobadas en la historia oficial del proyecto, y por qué SSH y OpenSSH sostienen hoy buena parte de la administración de sistemas.
Cloudflare ha estrenado página para sus Quick Tunnels: un comando, sin cuenta y sin abrir puertos, y tu servidor local tiene una URL pública con HTTPS. Lo hemos probado con la versión de septiembre, que añade túneles protegidos por correo y salida para agentes. Explicamos cómo funciona, los límites que están en la documentación y no en la portada, por qué los equipos de seguridad lo vigilan, y qué alternativas hay, de ngrok y Tailscale Funnel a frp, zrok o Pangolin en un servidor propio.