En el uso habitual, ZFS está diseñado para evitar la corrupción de datos, pero en fase de desarrollo puede ser útil provocarla de forma controlada y reproducible: sirve para observar la auto-curación del sistema, comprobar qué reporta un scrub o entender cómo se mapea un archivo sobre el disco físico. El artículo describe cómo hacerlo en Linux sobre pools respaldados por ficheros en lugar de discos reales.
La vía rápida es zinject, una herramienta que inyecta errores simulados de checksum en un pool activo y que se usa mucho en la suite de pruebas de ZFS. Resulta práctica, pero no explica dónde viven los bytes. Para aprender eso, el autor propone crear dos pools a partir de ficheros: uno de vdev único, sin redundancia, y otro RAIDZ2 de cuatro discos.
Sobre el pool simple escribe un fichero de 1 MiB con un patrón reconocible, obtiene su inodo y lo pasa a zdb, que devuelve la lista de bloques con sus direcciones virtuales (DVA). Cada DVA codifica el vdev, el desplazamiento y el tamaño en disco. ZFS reserva los primeros 4 MiB de cada vdev para etiquetas y boot block, por lo que el byte físico se calcula sumando 0x400000 al desplazamiento de la DVA y dividiendo entre 512. Aplicando la fórmula, el primer bloque de datos cae en el sector 8397 del fichero de respaldo, y un dd con hexdump lo confirma mostrando la cadena SINGLE-ZFS-CORRUPTION-DEMO-BLOCK. A partir de ahí se puede alterar un byte con un editor hex y comprobar cómo ZFS detecta la incoherencia.