Como se discutió en la Parte 1 de esta serie, Stratis es un sistema de archivos de administración de volumen (VMF) con una funcionalidad similar a ZFS y Btrfs. Al diseñar Stratis, estudiamos las opciones que tomaron los desarrolladores de las soluciones existentes.
¿Por qué no adoptar una solución existente?
Las razones varían. Primero, consideremos ZFS. Originalmente desarrollado por Sun Microsystems para Solaris (ahora propiedad de Oracle), ZFS ha sido portado a Linux. Sin embargo, su código con licencia CDDL no se puede fusionar con el árbol fuente de Linux con licencia GPL. Si CDDL y GPLv2 son realmente incompatibles es un tema de debate, pero la incertidumbre es suficiente para que los proveedores de Linux empresarial no estén dispuestos a adoptarlo y admitirlo.
Btrfs también está bien establecido y no tiene problemas de licencia. Durante años fue el "Elegido" para muchos usuarios, pero aún no ha llegado a donde debe estar en términos de estabilidad y funciones.
Entonces, impulsado por el deseo de mejorar el statu quo y la frustración con las opciones existentes, se concibió Stratis.
En qué se diferencia Stratis
Más recursos de Linux
- Hoja de trucos de los comandos de Linux
- Hoja de trucos de comandos avanzados de Linux
- Curso en línea gratuito:Descripción general técnica de RHEL
- Hoja de trucos de red de Linux
- Hoja de trucos de SELinux
- Hoja de trucos de los comandos comunes de Linux
- ¿Qué son los contenedores de Linux?
- Nuestros últimos artículos sobre Linux
Una cosa que ZFS y Btrfs han demostrado claramente es que escribir un VMF como un sistema de archivos en el núcleo requiere una gran cantidad de trabajo y tiempo para solucionar los errores y estabilizarlo. Es esencial acertar cuando se trata de datos valiosos. Comenzar desde cero y adoptar el mismo enfoque con Stratis probablemente también llevaría una década, lo cual no era aceptable.
En su lugar, Stratis optó por utilizar algunas de las otras capacidades existentes del kernel de Linux:el subsistema mapeador de dispositivos, que LVM utiliza principalmente para proporcionar RAID, aprovisionamiento delgado y otras características además de los dispositivos de bloque; y el sistema de archivos XFS bien probado y de alto rendimiento. Stratis construye su grupo utilizando capas de tecnología existente, con el objetivo de administrarlas para que parezcan un todo perfecto para el usuario.
Lo que Stratis aprendió de ZFS
Para muchos usuarios, ZFS estableció las expectativas de lo que debería ser un sistema de archivos de próxima generación. La lectura de comentarios en línea de personas que hablaban sobre ZFS ayudó a establecer los objetivos de desarrollo iniciales de Stratis. El diseño de ZFS también resaltó implícitamente las cosas que se deben evitar. Por ejemplo, ZFS requiere un paso de "importación" al adjuntar un grupo creado en otro sistema. Hay algunas razones para esto, y cada razón probablemente fue un problema que Stratis tuvo que resolver, ya sea adoptando el mismo enfoque o uno diferente.
Una cosa que no nos gustó de ZFS fue que tiene algunas restricciones para agregar nuevos discos duros o reemplazar los existentes por otros más grandes, especialmente si el grupo está configurado para redundancia. Por supuesto, hay una razón para esto, pero pensamos que era un área que podíamos mejorar.
Finalmente, usar las herramientas de ZFS en la línea de comando, una vez que se aprende, es una buena experiencia. Queríamos tener esa misma sensación con la herramienta de línea de comandos de Stratis, y también nos gustó la tendencia de la herramienta de usar parámetros posicionales y limitar la cantidad de escritura requerida para cada comando.
Lo que Stratis aprendió de Btrfs
Una cosa que nos gustó de Btrfs fue la herramienta de línea de comandos única, con subcomandos posicionales. Btrfs también trata la redundancia (perfiles Btrfs) como una propiedad del grupo, lo que parece más fácil de entender que el enfoque de ZFS y permite agregar e incluso eliminar unidades.
Finalmente, observar las funciones que ofrecen tanto ZFS como Btrfs, como implementaciones de instantáneas y soporte de envío/recepción, ayudó a determinar qué funciones debería incluir Stratis.
Lo que Stratis aprendió de LVM
Desde las primeras etapas de diseño de Stratis, estudiamos LVM extensamente. LVM es actualmente el usuario más importante del subsistema del mapeador de dispositivos (DM) de Linux; de hecho, el equipo principal de LVM mantiene DM. Lo examinamos tanto desde la posibilidad de realmente usar LVM como una capa de Stratis y un ejemplo del uso de DM, que Stratis podría hacer directamente con LVM como par. Analizamos el formato de metadatos en disco de LVM (junto con ZFS y XFS) en busca de inspiración para definir el formato de metadatos en disco de Stratis.
Entre los proyectos enumerados, LVM tiene más en común con Stratis internamente, porque ambos usan DM. Sin embargo, desde el punto de vista del uso, LVM es mucho más transparente sobre su funcionamiento interno. Esto brinda a los usuarios expertos una gran cantidad de control y opciones para configurar con precisión el diseño del grupo de volúmenes (piscina) de una manera que Stratis no lo hace.
Diversidad de soluciones
Una gran ventaja de trabajar con software libre y código abierto es que no hay componentes irremplazables. Cada parte, incluso el kernel, está abierta para su visualización, modificación e incluso reemplazo si el software actual no satisface las necesidades de los usuarios. No es necesario que un nuevo proyecto termine con uno existente si hay suficiente apoyo para que ambos se mantengan en paralelo.
Stratis es un intento de conocer mejor a algunos necesidades de los usuarios para la gestión del almacenamiento local:aquellos que buscan una solución potente, fácil de usar y sin complicaciones. Esto significa tomar decisiones de diseño que podrían no ser adecuadas para todos los usuarios. Las alternativas hacen posibles las decisiones difíciles ya que los usuarios tienen otras opciones. En última instancia, todos los usuarios se benefician de su capacidad para utilizar la herramienta que mejor se adapte a sus necesidades.