ZFS de Sun, ¿futuro sistema de archivos de los Xserve?

En la lista de distribución sobre el sistema de archivos ZFS, creado por Sun Microsystems, acaban de enviar este mensaje:

¡Aquí va una noticia muy interesante!

Chris Emura, el Jefe de Desarrollo de Sistemas de Archivos dentro del núcleo de sistema operativo de Apple está interesado en portar ZFS a OS X. Si queréis más información, enviadle un mensaje de correo electrónico a cemura arroba apple punto com.

Hablando en nombre del equipo zfs (de Sun), consideron que es una gran noticia, y apoyamos por completo el esfuerzo.

Sistemas de Archivos

Pero, ¿qué es un sistema de archivos? De la wikipedia sacamos esta definición:

En computación, un sistema de archivos es un método de almacenamiento y organización de archivos de computadora, y de los datos que contienen, para que sea fácil encontrarlos y acceder a ellos. Los sistemas de archivos pueden utilizar un dispositivo de almacenamiento, como un disco duro o un CD-ROM, e implican el seguir la pista a la localización física de los archivos, o pueden ser virtuales, y existir sólo como métodos de acceso a datos virtuales, o a datos en una red local.

Siendo más formales, diremos que un sistema de archivos es un conjunto de tipos de datos abstractos que se implementan para el almacenamiento, organización jerárquica, organización, manipulación, navegación, acceso y recuperación de datos.

Después de ese peñazo, que nos sirve para definir lo que es un sistema de archivos, diremos que el Macintosh ha conocido varios de ellos. El primero, MFS, por Macintosh File System, permitía crear carpetas para agrupar los archivos, pero esas carpetas sólo existían para visualizar los archivos: todos los archivos, en realidad, se encontraban en una única lista, y por tanto no podían existir archivos con el mismo nombre en el mismo disco, aunque se visualizaran en carpetas distintas.

Aún así, era bastante apropiado para los disquetes, y permitía usar nombres largos, identificación de tipo de archivo y aplicación creadora fuera del nombre del archivo, etcétera.

El segundo sistema de archivos, que duró hasta la presentación del Mac OS 8.1, fue el HFS, o Hierarchical File System. Mantenía los nombres de 31 caracteres, y permitía información adicional, como etiquetas, carpetas de tamaños arbitrarios, movimiento instantáneo de archivos entre carpetas del mismo disco…

Con la presentación de Mac OS 8.1, Apple introdujo HFS+ —nombrado por el Finder y otras utilidades como Mac OS Plus—, que permitía nombres realmente largos —más de 31 caracteres—, que podían estar en cualquier idioma —gracias a Unicode—, y sobre todo permitiendo que se pudieran crear archivos más grandes, de hasta 8 Exabytes (o casi 10 mil millones de GB).

h3. ¿Qué ofrece, entonces, ZFS?

Igual que pasar de números de 32 bits a números de 64 bits permitió pasar de 2GB de tamaño máximo a 16 mil millones de GB… ZFS utiliza números de 128 bits para los tamaños de sus archivos, de modo que estaríamos hablando de trillones —millones de millones de millones— de GB… Tantos, que se considera prácticamente imposible que exista ningún medio de almacenamiento que pueda ser mayor que lo que se puede gestionar con ZFS, porque el número de partículas del universo es inferior… y de algo habrá que hacer los discos duros 😉

La capacidad de direccionar información de ZFS es tan grande, que lo que se hace es distribuir los archivos en diferentes _pools_, o zonas de almacenamiento, que son transparentes a la hora de acceder al sistema de archivos. Sun dice que ZFS es a los sistemas de archivos como la memoria virtual es a la memoria.

Otra capacidad, posiblemente la más interesante, es la de GARANTIZAR la integridad de los datos. En un sistema ZFS, un dato que está en disco siempre se graba bien… y se puede comprobar que no está bien, o que ha sido alterado de forma ajena al sistema de archivos —algo que sólo puede ser un error— en la primera relectura que se haga del archivo. No pueden existir errores “silenciosos”.

Además, también se garantiza la escritura por _transacciones_. Esto significa que no hay que llevar un _registro_ de operaciones en disco que reconstruir en caso de fallo: el estado del disco siempre es coherente. Un apagón no puede dejar ningún disco ZFS en un estado incoherente. Y una subida de tensión, que alterase bits en los datos, sería registrada.

Aún mejor: ZFS dispone de un sistema de _instantáneas_ (snapshots) del sistema de archivos, que permite retroceder al estado que tenía el sistema de archivos en cualquier momento pasado. Y por la forma en que se hacen las escrituras, y se garantiza la coherencia, es más sencillo mantener esas _instantáneas_ que descartarlas. Y como las _instantáneas_ contienen información suficiente no sólo para detectar errores, sino también para repararlos… la mayoría de los fallos que se pueden producir en un disco ZFS son recuperables, y en el peor de los casos, una versión anterior del fichero es recuperable. Esas _instantáneas_, además, sólo se producen de los archivos que cambian. Los archivos que no cambian no ocupan espacio adicional en disco.

Todo lo anterior tiene pinta de hacer el sistema de archivos muy lento. Y lo sería, para aplicaciones que accediesen al disco a bajo nivel. Pero ZFS organiza las escrituras y lecturas de forma que se agrupan previamente las operaciones, acelerando las escrituras, y todos los pasos necesarios para las verificaciones exhaustivas propias de ZFS.

Por último, y posiblemente lo más importante desde un punto de vista de tecnología con toque Apple, ZFS abstrae completamente del usuario, e incluso del administrador, una vez configurado, la noción de disco y volumen, y todo vive en un mismo _pool_ de información. Imaginad que le pudierais poner un disco duro externo al portátil, y automáticamente tuviéseis más capacidad en un único “disco”, y que en cuanto se desconectase dejaseis de tenerla de forma transparente. Adiós a las particiones, salvo las que no existiesen dentro de ZFS, y que fueran necesarias para otros sistemas operativos, menos avanzados…

h3. Lo que no ofrece ZFS

Pues, en primer lugar, por todo lo que implementa, ZFS no es el sistema de archivos más rápido del mundo para operaciones por bloques… aunque sí es el más rápido que ofrece sus características (algo que es tautológico, puesto que ninguno ofrece lo mismo 😉 ),

Además, la ocupación del disco es mucho mayor que con cualquier otro sistema, debido al sistema de imágenes, y la ocupación de memoria también, por la necesidad de crear en RAM todas las transacciones antes de intentar realizarlas en disco.

Lo que esto quiere decir es que, probablemente, no sea algo que vaya a sustituir a HFS+ como sistema de archivos estándar, pero sí puede ser una opción, especialmente en Mac OS X Server, y para la gestión de grandes volúmenes de datos, como los que puede manejar Xsan. De hecho, Xsan se queda en los 2 PB de tamaño de archivo (2 millones de GB).

Aún así, es muy interesante que Apple se interese en ZFS, tanto para usarlo como sistema de archivos alternativo —o como base para un Xsan 2.0—, como para utilizar partes de ZFS para evolucionar HFS+… Y en todo caso, no creo que vaya a formar parte de Leopard (Mac OS X 10.5), pero muy posiblemente sí de Mac OS X 10.6, si no se trata, como ya he dicho, de algo exclusivo para Xsan.

h3. Enlaces

* OpenSolaris: “Porting ZFS to OSX”:http://mail.opensolaris.org/pipermail/zfs-discuss/2006-April/002119.html
* Wikipedia: “Sistema de Archivos”:http://es.wikipedia.org/wiki/Sistema_de_archivos
* Wikipedia: “File systems”:http://en.wikipedia.org/wiki/Filesystem
* Wikipedia: “Exabyte”:http://es.wikipedia.org/wiki/Exabyte
* Wikipedia: “ZFS”:http://es.wikipedia.org/wiki/ZFS_(sistema_de_archivos)
* OpenSolaris: “ZFS Overview (PDF)”:http://www.opensolaris.org/os/community/zfs/docs/zfs_last.pdf
* Apple Developer Connection: “HFS Plus Volume Format”:http://developer.apple.com/technotes/tn/tn1150.html
* Apple España: “Xsan”:http://www.apple.com/es/xsan/
* John Siracusa: “Who’s minding the store?”:http://arstechnica.com/staff/fatbits.ars/2005/11/20/1886
* John Siracusa: “ZFS data integrity explained”:http://arstechnica.com/staff/fatbits.ars/2005/12/9/2049
* Vía “FatBits”:http://arstechnica.com/staff/fatbits.ars/2006/4/27/3777