Reflexiones de Theodore Ts’o, el creador del sistema de archivos Ext4, sobre el desarrollo de ext4, el sistema de archivos BcacheFS, el núcleo de Linux, el código de conducta y los sistemas de archivos en general:
Sobre el desarrollo de ext4.
En cada lanzamiento del núcleo, más de una docena de personas contribuyen. Actualmente, la mayor parte de mi tiempo se dedica a revisar código, realizar pruebas y mejorar la aplicación de pruebas {kvm,gce,qemu,android}-xfstests. Y confío mucho en 2-3 desarrolladores más que trabajan en SUSE e IBM, quienes me ayudan con la revisión del código.
Sobre BcacheFS
Honestamente, bcachefs no es un proyecto completamente individual; por ejemplo, Kent fue autor del 72% de los parches entre las versiones del núcleo 6.11 y 6.12, mientras que de 103 parches a ext4 durante el mismo período, yo no fui autor de ninguno. Esto se debe a que sostengo firmemente la opinión de que la programación es un deporte de equipo y mi trabajo como líder técnico es empoderar a los participantes de ext4 para que hagan todo lo posible para mejorar el sistema de archivos. Realizamos conferencias semanales, y Derrick Wong, desarrollador senior de XFS y ex-mantenedor de XFS, participa en estas reuniones; y, como es sabido, le he ayudado en cuestiones de pruebas de XFS, mientras que Derrick me ha asistido en diversas pruebas de ext4 e incluso ha revisado un par de parches de ext4. Colaboramos entre nosotros, y eso es bueno.
Dejo que otras personas decidan si quieren confiar sus datos a alguien que es un programador solitario que podría ser más talentoso que yo, pero les daré un consejo: pueden "hacer trampa" al involucrar a un equipo para resolver un problema. No es necesario hacerlo solo. Por supuesto, para esto, deben saber cómo despertar lo mejor en los demás y deben trabajar juntos. Y ser cortés entre sí en las listas de correo no está de más.
Sobre el núcleo, CoC, capacidades y el futuro de ext4
Ext4 realmente está recibiendo algunas nuevas funciones, pero estas son las que las empresas están dispuestas a financiar, porque el retorno de la inversión en el desarrollo de la función tiene sentido en términos de costos y beneficios. Por ejemplo, fscrypt y los directorios sin distinción de mayúsculas y minúsculas eran funciones útiles para Android y Chrome OS, y fueron financiadas, al menos en parte, por estos grupos de desarrolladores (Steam también estaba preocupado por la distinción entre mayúsculas y minúsculas y apoyó a uno de los ingenieros). Queremos agregar soporte para escrituras no interrumpidas (untorn) porque esto mejorará el rendimiento de las bases de datos en dispositivos de almacenamiento en bloque emulados en la nube, donde se pueden garantizar 16k de registros atómicos, lo que eliminará la doble memorización en MySQL y PostgreSQL.
(En realidad, Amazon y Google pueden hacer esto en sus propios productos de DBMS, haciendo suposiciones sobre cómo funcionan Amazon EBS y Google Persistent Disk, pero queremos hacerlo de una manera más general que sea más sostenible a largo plazo). Esto es menos atractivo que cosas como reflinks, pero el retorno sobre la inversión es mucho más fácil de justificar, tanto porque los costos son más bajos (menos trabajo en desarrollo, pruebas y calificación para el despliegue empresarial), como porque los beneficios son mucho más fáciles de valorar cuantitativamente. Cosas como "puedo ahorrar el costo de XX ingenieros programadores durante cinco años" son mucho más fáciles de lograr para este tipo de funciones de mejora del rendimiento.
En contraste, reflinks son divertidos, pero no pude encontrar un cliente dispuesto a cubrir los costos de desarrollo, ni una empresa que crea que sus clientes comprarán más de su producto si agregan reflinks a ext4. Puede parecer terriblemente corporativo, pero hay una historia sobre cómo los ingenieros de ZFS comenzaron un proyecto desde cero, sin pedir permiso a la gerencia ni recibir propuestas del departamento de ventas, y presentaron a Sun lo que prácticamente era un hecho consumado.
Suena genial, pero si recordamos que al final Sun empezó a perder dinero hasta verse obligada a venderse a otra compañía, y que de hecho la organización de ingeniería que apoyaba ZFS ya no existe. Aproximadamente en el momento en que se anunció ZFS, participé en una investigación en toda la empresa sobre si tenía sentido invertir en funciones de sistemas de archivos para AIX y Linux, y llegamos a la conclusión de que no; el retorno de la inversión era bajo y las nuevas funciones de sistema de archivos no atraerían a más clientes para que compraran hardware, software o sistemas IBM. Puede que para IBM fueran tiempos difíciles, pero todavía existe, mientras que Sun no.
Aproximadamente en ese mismo tiempo, representantes de varias empresas de Linux se reunieron para idear cómo competiría Linux con ZFS. Fue en esta reunión donde se propuso la idea de que btrfs sería la respuesta a largo plazo, y ext4 una solución a corto plazo que proporcionaría soporte para cosas como el cambio de tamaño en tiempo real, números de bloques de 64 bits y otras funciones que estaban presentes en los sistemas operativos Unix Legacy tradicionales y que no estaban en ext3.
En esa reunión se me pidió que definiera qué se necesitaría para crear un sistema de archivos completamente nuevo. Hice una investigación viendo cuántos esfuerzos se requirieron para crear sistemas de archivos como GPFS y JFS de IBM, advfs de Digital, y evalué cuánto le llevó a Sun crear ZFS y llevar este sistema de archivos a un estado completamente listo para producción. La respuesta que obtuve fue aproximadamente 100 personas-año, con una estimación baja de 50 personas-año y una alta de 200 personas-año (pero eso era para GPFS, que era un sistema de archivos en clúster y por lo tanto mucho más complejo).
Informé sobre esto en la reunión, y un ingeniero senior de Intel dijo: "No, no digas esto a los directivos, porque nunca aprobarán el proyecto. Diles que btrfs estará listo en 18 meses". Dejo que la gente decida por sí misma cuándo btrfs alcanzará el estado de "listo para uso empresarial", especialmente para aquellas nuevas funciones ampliadas atractivas que debían competir con ZFS, pero no creo que sea discutible que esto no ocurrió en 18 meses.
Y incluso antes de que Sun se disolviera, muchas empresas que enviaron representantes a la reunión se negaron a que sus ingenieros trabajaran en btrfs, lo que, por supuesto, no ayudó. Pero probablemente estaba relacionado con el hecho de que las empresas son organizaciones racionales que toman sus propias decisiones sobre la rentabilidad de las inversiones, y financiar un nuevo sistema de archivos no tenía tanto sentido como contarle a la gente que Linux tendría una respuesta para ZFS.
Mirando hacia atrás, se puede decir que, aunque ZFS tenía realmente características geniales, no eran suficientes para hacer que la mayoría de los usuarios eligieran Solaris en comparación con la compra de plataformas x86 mucho más baratas e instalar Linux. Y para cuando Sun decidió intentar la estrategia de OpenSolaris y Solaris x86, ya era demasiado tarde. Los efectos de red eran enormes, y la estrategia de x86 no respondía a la pregunta de cómo una sola empresa, Sun, podía pagar los salarios de todos los supertalentos que trabajaban en Solaris. Comprar un servidor x86 por 5000 dólares no ofrece un gran retorno de inversión en comparación con el servidor SunFire E10k Sparc por 100000 dólares, que Sun llamaba 'el punto' en '.com'.
La esencia es que la ingeniería en el mundo real es un compromiso, y las realidades empresariales son parte de ese compromiso. No me disculpo por preferir comer, y quiero ganar suficiente dinero para algún día jubilarme. Y eso, a su vez, significa que debo entender bien cómo aporto valor a mi empleador, al menos 10 veces más de lo que es mi salario. Si puedo hacer esto, continuando trabajando con código abierto y ayudando a otras empresas a ganar dinero para que estén dispuestas a contribuir a ext4, bueno, eso es parte del desafío y la razón por la que me encanta trabajar con código abierto.
Y, volviendo al Código de Conducta, diré que casi todos los mantenedores de los sistemas de archivos principales apoyaron el Código no por razones liberales débiles. Es porque necesitamos a cada ingeniero dispuesto a contribuir a nuestro proyecto, y la mayoría de nosotros hemos visto a personas que se negaron a trabajar en Linux y se pasaron a otros sistemas operativos (conozco a una persona que se pasó a Windows y era un valioso desarrollador del núcleo de Linux en el Centro de Tecnología de Linux de IBM) o trabajaron en proyectos internos, pero no en aquellos que requerían interacción con LKML, debido al ambiente tóxico de algunas personas en la lista de correo.
En algunos casos, las preocupaciones eran infundadas; por ejemplo, Linus gritó a un desarrollador senior que realmente debería haber sabido más y con quien Linus se había reunido en persona en la mayoría de los casos, y ya tenían una relación establecida. El problema es que los nuevos no sabían esto y se asustaban: «¿y si Linus me humilla públicamente como hizo con Steve?», sin comprender que en la práctica esto no sucederá. Por eso tenemos el CoC; no es para nosotros, los ingenieros senior, sino para apoyar a los ingenieros más jóvenes en nuestros equipos, a quienes queremos capacitar para que eventualmente nos reemplacen cuando llegue el momento de jubilarnos, o cuando un autobús nos atropelle, o de alguna otra manera dejemos este mundo mortal.
No olvides los 50-100 años-hombre de trabajo para crear un sistema de archivos listo para el uso en un entorno corporativo. Necesitamos a todos los ingenieros que podamos atraer, y muchos de nosotros realizamos trabajo adicional en nuestro tiempo libre porque nos importa. Crear un sistema de archivos de alta calidad es un trabajo en equipo, y necesitamos a cada ingeniero talentoso que podamos conseguir. Incluso si un ingeniero es un programador super 10x, si al final ahuyenta a un montón de otros ingenieros que podrían trabajar en pruebas, ajuste de rendimiento, etc., simplemente no vale la pena permitir que alguien sea un villano.
Fuente: opennet.ru
