BTRFS vs OpenZFS
Mecanismo de copia en escritura (vaca)
Ambos sistemas de archivos utilizan el mecanismo de copia en escritura. Esto significa que, si está intentando modificar un archivo, ninguno de los sistemas de archivos intentará sobrescribir los datos existentes en el disco con los datos más nuevos. En cambio, los datos más nuevos se escriben en otro lugar y una vez que se completa la operación de escritura, el sistema de archivos simplemente apunta a los bloques de datos más nuevos y los bloques antiguos se recicla con el tiempo. Este mecanismo permite que ambos sistemas de archivos tengan características como instantáneas y clonación.
La vaca también previene casos de borde como las escrituras parciales, que pueden ocurrir debido al pánico del núcleo o la falla de energía y potencialmente corromper todo su sistema de archivos completo. Con la vaca en su lugar, ha sucedido una escritura o no ha sucedido, no hay en el medio.
Piscina y incursión
Tanto los sistemas de archivos tienen la intención de eliminar la necesidad de un administrador de volumen, RAID y otras abstracciones que se encuentran entre el sistema de archivos y los discos. Esto es más robusto y confiable que tener un controlador RAID de hardware, simplemente porque elimina un solo punto de falla: el controlador RAID en sí mismo.
OpenZFS ofrece un mecanismo de incursión estable, confiable y fácil de usar. Puede reflejar entre unidades, usar RAIDZ1 que difunde sus datos en 3 o más disco con un bloque de paridad. Entonces puede resistir la falla del disco de Upton 1 por VDEV. Del mismo modo, RAIDZ2 puede usar 4 o más discos y soportar hasta 2 discos que falla y, de manera similar, tenemos RAIDZ3.
BTRFS también tiene estas características implementadas, la diferencia es simplemente que los llama RAID, en lugar de Raidz, etc. Algunas configuraciones de matriz de incursión más complicadas como RAID56 son erróneas y no están adecuadas para su uso, al momento de escribir este artículo.
Licencia
Una de las razones por las que OpenZFS llegó tan tarde en el ecosistema GNU/Linux se debe a su incompatibilidad de licencia con GNU GPL. Sin entrar en demasiados detalles, BTRFS está en GPL, lo que permite a los usuarios tomar el código fuente y modificarlo, pero las modificaciones también deben publicarse bajo GPL y mantenerse de código abierto.
OpenZFS, por otro lado, tiene licencia bajo CDDL, que es mucho más permisiva y permite a los usuarios modificar y distribuir código con un mayor grado de libertad.
Comunidades y empresas detrás de ellos
OpenZFS tiene una comunidad masiva detrás. Comunidad FreeBSD, Comunidad Illumos y muchos otros proyectos de código abierto dependen de OpenZFS y, por lo tanto, contribuyen al sistema de archivos. Ha crecido varios veces en términos de base de código, base de usuarios, características y flexibilidad desde su inicio. Empresas como Delphix, IXSystems, Joyent y muchos más confían en él y hacen que sus desarrolladores trabajen porque es un componente central de su negocio. Muchas más organizaciones podrían estar utilizando OpenZFs sin nuestro conocimiento, gracias a la licencia de CDDL, no tienen que salir y decir que lo usan.
BTRFS tenía a Red Hat como uno de los principales administradores de su comunidad. Sin embargo, eso recibió un golpe importante hace un tiempo cuando Red Hat desaprobó el sistema de archivos, esto significa que no lo verá en ningún futuro RHEL y la compañía no brindará soporte comercial fuera de la caja. SUSE, sin embargo, ha ido tan lejos como para que sea su incumplimiento y sigue siendo una comunidad próspera detrás del sistema de archivos con contribuciones de Facebook, Intel y otros gorilas de 800 libras del valle de Silicon.
Fiabilidad
ZFS fue diseñado ser confiable desde el principio. Las personas tienen zpools que se remontan a principios de la década de 2000 que aún se utilizan y garantizan que no devuelvan datos erróneos en silencio. Sí, ha habido algunos abetos con archivos que desaparecen para OpenZFS en Linux, pero dada su larga historia, el historial ha sido sorprendente limpio.
BTRFS, por otro lado, ha tenido problemas desde el principio. Con interfaces con errores para la pérdida de datos y la corrupción de archivos. Incluso ahora, es un poco risueño en la comunidad. Haz de eso lo que harás.
OSE apoyados
BTRFS ha tenido su origen tiene un sistema de archivos para Linux, mientras que ZFS fue concebido dentro de Sun, para Solaris OS. Sin embargo, OpenZFS se ha portado desde hace mucho tiempo a FreeBSD, OS X de Apple, derivados de código abierto de Solaris. Su apoyo para Linux llegó un poco más tarde de lo que uno hubiera predicho, pero es aquí y las corporaciones confían en ello. Un proyecto para que se ejecute en Microsoft Windows también está avanzando bastante, aunque aún no está allí.
Conclusión: una nota sobre monocultivos
Toda esta charla puede convencerlo de que use OpenZFS para mantener sus datos seguros, y ese no es un mal curso de acción. Es objetivamente mejor que BTRFS en términos de características, confiabilidad, comunidad y mucho más. Sin embargo, a la larga, esto podría no ser bueno para la comunidad de código abierto, en general.
En una publicación titulada similar a este, el autor habla sobre lo peligroso de los monocultivos. Te animo a que pases por esta publicación. La esencia de esto es esto - Las opciones son importantes. Una de las mayores fortalezas del software de código abierto (y el software, en general) es que tenemos múltiples opciones para adoptar. Hay Apache y luego está Nginx, hay BSD y Linux, hay OpenSSL y hay libressl.
Si hay una falla fatal en cualquiera de estas tecnologías clave, el mundo no dejará de girar. Pero con la prevalencia de OpenZFS, la tecnología de almacenamiento se ha convertido en una especie de monocultivo. Por lo tanto, me gustaría mucho que los desarrolladores y programadores de sistemas que están leyendo esto, adoptan no OpenZFs, sino proyectos como BTRFS y Hammer.