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
Menos mal que ellos mismo dijeron hace tiempo que iba a ser su sistema de ficheros por defecto en un futuro.
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.
#2 precisamente lo que quiere RH es extender LVM (o semejante) para lograr la misma funcionalidad (o casi) que hay con Btrfs y ZFS. Han adquirido una compañía que hace cosas parecidas y un montón de desarrolladores de XFS.
Ya veremos lo que logran, pero soy igual de escéptico que tú.
#7 Algunos dicen por ahí que el siguiente hype va a ser Bcachefs http://bcachefs.org/
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.
#9 Hace años se utilizaba Red Hat en el curro, sobretodo en radiología, viniendo de UNIX lo que puedo decir de entonces es que el sistema de archivos que se utilzaba era el XFS e iba cohonudo, y por otra y por pura casualidad hace relativamente poco tiempo tuve la oportunidad de trastear un poco con él ya que Cofares lo utiliza y según me comentó el farmaceútico les causa muchos problemas en gral. y por eso muuchos migran a Windows
#11 Joder, qué putada.
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).
#12 Yo también he acabado usando Ubuntu LTS en mis proyectos, aunque antes ya usaba CentOS por lo que me ahorraba el soporte de Red Hat. Personalmente creo que Ubuntu ha hecho un gran trabajo con LXD, un sistema de contenedores ligero y pensado para ser muy intuitivo de administrar que además se integra perfectamente con Btrfs/ZFS. Pero siendo realista, Red Hat seguirá imponiendo su forma de hacer las cosas en temas de servidores y LXD acabará eclipsado por el éxito de Docker (aunque sean sistemas de contenedores muy diferentes).
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...
#16 Ah… LXD. Qué verdadera maravilla están haciendo con ese software. Y aunque no es comparable a Docker (no hacen lo mismo), es especialmente bueno para aislar y simular entornos.
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. https://thehftguy.com/2016/11/01/docker-in-production-an-history-of-failure/
#12 ¿Salir de las LTS? ¿En producción? ¿Sin soporte? ¿En un entorno complejo?
No se, no se....
#20 Nuestra “producción” es ordenadores para desarrolladores cuyo trabajo está siempre bien protegido en un sistema de control de versiones, así que eso no me preocupa. Pasaría a la última siempre porque es mejor para su trabajo diario.
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).
#2 Bueno, ahora LVM integra las capacidades de RAID que permiten que nos deshagamos de mdadm..... pero yo no me atrevo.
Algún consejo? RAID con LVM o LVM+mdadm?
Lo que no sé es por qué no usan ReiserFS, aprovechando que Hans Reiser tiene mucho tiempo libre.
Bueno, más bien tiene mucho tiempo disponible, porque libre, lo que se dice libre...
Han dado por imposible pronunciar eso sin escupir al de enfrente
#1 Better FS
#3 No acabo de entender porque en Linux se empeñan en asignar nombres tan crípticos a las cosas, creo que es parte de la culpa de la baja acogida por parte del usuario estándar, ¿es por ahorrar caracteres en modo terminal?
#4 De hecho lo instintivo es pronunciar bitter ef es. Lo cual queda fatal.
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.
#5 el usuario estándar que busque ayuda en Internet se va a dar de bruces con toda esa terminología aunque el uso diario del SO no lo requiera.
#5 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
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?
#3 Butter FS
/cc #1 #3 #4
#4 ¿? Qué tiene que ver esto con Linux?. Es un sistema de archivos, como si NTFS fuera la maravilla explicativa....
Habia leido "Red Hat deja de dar soporte al Betis" y me he quedado
Para compensarlo, que hagan un port y ayuden al desarrollo de HAMMER2
🔗 https://www.dragonflybsd.org/hammer
Gracias Red Hat. Total, sólo tenemos ~250TB de información en BTRFS ahora mismo
#10 Eso no es complicado de migrar..... si tienes sitio.