Por qué un snapshot ZFS de 60GB ocupó 5TB: la trampa del thin provisioning

El momento en que todo deja de tener sentido

Crees que entiendes los snapshots. Todo el mundo lo cree: congelas el disco, registras los cambios y a otra cosa. Ha funcionado así durante años en todas las plataformas, así que cuando algo pasa de 60GB a varios terabytes, tu primer instinto es el pánico, y la curiosidad llega mucho después.

Ahí empieza esta historia. Una expectativa sencilla choca con una sorpresa fea: crear un snapshot de repente duplica el uso del disco. No es una pequeña sobrecarga ni un error de redondeo; tiene toda la pinta de una duplicación completa. "¿Por qué un snapshot de 60GB se está comiendo 5TB?" suena menos a pregunta que a incredulidad.

Lo peor es que, a primera vista, nada parece estar mal. La interfaz dice una cosa, ZFS dice otra y, en algún punto intermedio, tu pool de almacenamiento se sigue llenando.

El modelo mental engañoso: "los snapshots solo guardan los cambios"

Casi todo el mundo llega con la misma suposición: los snapshots son ligeros, guardan diferencias y son eficientes por diseño. Esa creencia está más incompleta que equivocada.

Una voz intentó volver a lo básico y señaló que los snapshots de ZFS "solo consumen la cantidad de espacio en disco de la columna 'refer'". Esa es la respuesta de manual, y es limpia, lógica y tranquilizadora.

Esa explicación se estrella contra la realidad cuando el uso del disco se duplica de todos modos, y la confusión se convierte en frustración. Ahora parece que el sistema te está mintiendo o, peor aún, haciendo algo tremendamente ineficiente por debajo. Spoiler: está haciendo exactamente lo que le dijiste que hiciera.

El culpable oculto: el aprovisionamiento grueso pasa factura

El punto de inflexión llega con un detalle engañosamente sencillo: el aprovisionamiento ligero (thin provisioning) no estaba activado, y esa única casilla lo cambia todo.

Sin thin provisioning, cada snapshot reserva en la práctica el tamaño completo del disco además de registrar los cambios. Cuando ese disco es de 6TB, las cuentas se ponen feas muy rápido, y lo que parece un snapshot "pequeño" se comporta como un clon completo en cuanto a la asignación de espacio.

Un comentario lo dijo en términos claros: si no activas el thin provisioning, "cada snapshot ocupará su tamaño completo en lugar de las diferencias". Esa es la pieza que faltaba. No es un bug ni una rareza de Proxmox, solo un desajuste de configuración entre lo que esperabas y la realidad.

La segunda trampa: "arreglarlo" no es instantáneo

A partir de aquí la cosa se vuelve todavía más frustrante. Encuentras la solución, cambias el ajuste y esperas que todo se corrija solo, y no pasa.

Activar el thin provisioning no arregla con efecto retroactivo los discos existentes. Un usuario lo explicó con claridad: "no hará nada por sí solo en los discos existentes". Darte cuenta de eso duele, porque la mala configuración ya está incrustada en la disposición actual de tu almacenamiento.

Ahora te toca lidiar con términos como refreservation, conversiones manuales y comandos que parecen mucho más invasivos que un simple interruptor. Lo que empezó como una duda sobre snapshots se ha convertido en un problema de migración de almacenamiento.

La fase de la revelación: "ah… fui yo"

Todo proceso de depuración tiene un momento en el que la confusión se aclara de golpe. En este caso casi se oye: "Ahora lo entiendo".

Ese cambio importa, porque el sistema se comportó exactamente como estaba diseñado y el malentendido estaba en cómo interactúan sus piezas. Aprovisionamiento grueso más discos grandes más snapshots es igual a un consumo de espacio enorme. Es predecible en cuanto lo ves e invisible hasta entonces.

Eso es lo que hace tan frustrante este tipo de problema. Visto en retrospectiva es sencillo, pero está enterrado detrás de suposiciones que parecen universales y resultan no serlo.

La división de fondo: puristas de ZFS frente a usuarios de la interfaz

La situación también deja al descubierto una división más profunda en cómo la gente aborda sistemas como Proxmox.

A un lado están los que piensan en ZFS nativo. Viven en zfs list, entienden refer frente a used y tratan la interfaz de Proxmox como una capa de comodidad. Para ellos, este problema es casi obvio: claro que los ajustes de aprovisionamiento afectan al comportamiento de los snapshots.

Al otro lado están los usuarios que confían en la abstracción. Esperan que los snapshots se comporten como en todas partes y cuentan con que la interfaz refleje la realidad sin reinterpretarla. Cuando no es así, parece que algo está roto, aunque no lo esté.

Ninguno de los dos lados se equivoca. Simplemente hablan idiomas ligeramente distintos.

Lo que esto te enseña de verdad

Si hay una conclusión, es que los sistemas de almacenamiento no perdonan las suposiciones, y ZFS las perdona menos que ninguno.

El aprovisionamiento ligero frente al grueso suena a un detalle menor hasta que te duplica el uso del disco. Los snapshots parecen ligeros hasta que heredan todo el peso de tu configuración. Y ajustes que parecen inofensivos pueden decidir cómo se asignan los terabytes por debajo.

Activar un ajuste es solo la mitad del arreglo; la otra mitad es entender el modelo que hay debajo. Cuando lo entiendes, el comportamiento deja de parecer aleatorio y empieza a parecer inevitable, y quizá esa sea la parte más frustrante de todas.