19 meneos
145 clics
Red Hat dejará de dar soporte a Btrfs
Ayer se publicó una nueva versión de Red Hat Enterprise Linux. Una actualización de mantenimiento de RHEL (7.4) que además de presentar mejoras de seguridad (USB Guard para limitar el uso de dispositivos USB en función del usuario, capacidades de auditoria actualizadas, soporte de SELinux en OverlayFS) y rendimiento, también trae algunos abandonos, como el del soporte del sistema de archivos Btrfs en futuras versiones de la distribución. Este es el comunicado que forma parte de la documentación de RHEL 7.4.
|
comentarios cerrados
Btrfs aun está sin terminar, aunque si no usas Raid 5/6 ni de-duplicación se considera estable, pero su única alternativa real es ZFS. Y ZFS es un sistema de ficheros mucho mejor y más maduro pero que nunca podrá integrarse directamente en el kernel Linux vanilla por temas de licencias. Por lo que el futuro de Btrfs está asegurado y Red Hat seguramente tendrá que volver a darle soporte No podemos seguir eternamente con ext4/xfs combinado con lvm y mdadm, es mucho mejor tener todo integrado en el sistema de archivos.
Pero los sistemas de ficheros no son interesantes para un usuario estándar. Los usuarios estándar que saben de que es NTFS. Ni falta que hace.
Ya me diras que más le da que más le da a un usuario de escritorio que su sistema de ficheros tenga soporte de checksums, COW, volúmenes, cuotas y demás. Con que no sea una ñapa superlimitada como FAT un usuario normal tiene de sobra.
De hecho para servidores ahora se prefiere sistemas de ficheros limitados convencionales (ext4, XFS) y montar un sistema de ficheros distribuido encima, en vez de usar ZFS o Btrfs.
Ya veremos lo que logran, pero soy igual de escéptico que tú.
Bueno, más bien tiene mucho tiempo disponible, porque libre, lo que se dice libre...
De todas formas, como dice #2, Btrfs tiene todo el sentido del mundo, porque es un tedio (y pérdida de rendimiento) usar VFS -> LVM -> ext4, cuando se podría usar VFS -> Btrfs de forma directa (o ZFS, que me gusta mucho pero tiene el problema de licencias que comentan).
La cuestión es que queremos un sistema de archivos como Btrfs pero que funcione y que sea estable. Yo lo uso en el trabajo y, de momento, ningún problema (ninguno serio, vamos), pero reconozco que hay cierto miedo a que falle.
De todas formas, el que use Red Hat en el trabajo debería ir a la cárcel. Para pagar lo que se paga es vergonzoso. Nosotros ahora nos pasamos a Ubuntu (con Btrfs, dos discos físicos como un lógico y con snapshots por doquier para duplicar compilaciones) y, oye, encantados. Aunque aún tengo que conseguir que nos salgamos de las LTS. Pero, vamos, a años luz de Red Hat y con soporte comercial similar (si se quiere).
/cc #1 #3 #4
www.dragonflybsd.org/hammer
Y es curioso porque en escritorio prefiero Fedora a Ubuntu. Usando una "Red Hat" en escritorio y Ubuntu en servidores, me lo dicen hace años y me quedo loco...
No, eso no. Pero las ventajas que proporciona todo eso al usuario le vienen de puta madre. ¿O le viene mal a un usuario un sistema de archivos que evite la corrupción de datos, optimice el espacio de almacenamiento y permita ampliar y disminuir dinámicamente el espacio disponible?
Algún consejo? RAID con LVM o LVM+mdadm?
No se, no se....
Y en servidores… pues tendría que analizarlo, porque teniendo granjas de servidores (o clusters, como quieras), es fácil estar siempre en la última versión gracias a la redundancia. Y más si tienes diversidad de sistemas operativos donde no en todos hay los mismos puntos de fallo (y se gestionan con cosas como Ansible o SaltStack, todos a la vez y con la misma sintaxis; ese no es el problema).
Mi ejemplo con LXD: teníamos Red Hat 6 para desarrollar una aplicación distribuible como binaria (no web). Esa aplicación sólo compila en Red Hat porque a los HINGINIEROS no les da la cabeza para hacer el sistema de compilación genérico. Y ahí estaba el mayor escoyo para no pasarse a Ubuntu: que no compilaba y “era mucho trabajo hacerla compilar”. La solución: usar LXD. Se hizo un entorno en CentOS 6 (el más similar a Red Hat 6), se instalaron las librerías necesarias y, sorpresa, todo funcionando en menos de dos semanas. Desde ahí estoy enamorado de LXD.
Pero tengo más ejemplos en el día a día: nuevo paquete de Debian que modifica la configuración. No lo debo hacer en mi propia máquina porque me modifica mi propia configuración. ¿Solución? LXD. Más: script peligroso (de los que borran cosas). Se prueba en LXD. ¿Que borra la máquina entera con un rm -rf? Nahhhh… otra nueva y listo. Y así, montones de cosas. LXD es maravilloso.
Por cierto, que no me olvido de Docker: para mí es bastante, bastante malo en lo que hace, no así su concepto, que parece bueno. thehftguy.com/2016/11/01/docker-in-production-an-history-of-failure/