Un año de patrocinio para el desarrollo de FreeBSD
(daemonology.net)- En una situación donde el mantenimiento de FreeBSD/EC2 y la ingeniería de releases chocaban dentro del tiempo voluntario de una sola persona, un año de patrocinio de Amazon hizo posible avanzar al mismo tiempo en la operación de releases y en las mejoras de la plataforma EC2
- El patrocinio era nominalmente de 40 horas mensuales a través de GitHub Sponsors, pero el trabajo real promedió 50 horas al mes, repartidas aproximadamente en 20/20/10 horas entre temas de EC2, avance de releases y otras tareas de ingeniería de releases
- Durante un año, mientras se gestionaban los lanzamientos de FreeBSD 13.4, 14.2, 13.5 y 14.3, también se trabajó en tareas prioritarias como el manejo de señales de apagado en AWS Graviton y el hotplug de dispositivos en EC2
- Para encontrar regresiones de rendimiento de arranque, se hicieron benchmarks de builds semanales de AMI de EC2 desde 2018, y se detectaron y corrigieron causas de latencia relacionadas con el tamaño del disco raíz, el sembrado de entropía en EFI, los grupos de transacciones de ZFS y cambios de IPv6 en IMDSv2
- Aunque el rol continuará tras el fin del patrocinio, habrá menos tiempo disponible para corregir directamente problemas justo antes de un release o para seguir empujando la lista de funciones de EC2
Cuellos de botella y distribución del tiempo antes del patrocinio
- El mantenimiento de FreeBSD/EC2 continúa desde que FreeBSD arrancó por primera vez en Amazon EC2 en 2010, y en noviembre de 2023 se sumó además el rol de líder de ingeniería de releases de FreeBSD
- Los pequeños apoyos de Antithesis y del Patreon de FreeBSD/EC2 no eran suficientes para sostener ambos roles
- La lista de funciones por implementar se había estancado
- Incluso cuando se detectaban anomalías, cada vez era más frecuente posponerlas por falta de tiempo para investigarlas
- A inicios de 2024 crecía la preocupación de ya no poder actuar como un “buen owner” de la plataforma FreeBSD/EC2
- En abril de 2024, al encontrar en Amazon a una persona responsable con presupuesto, comenzaron conversaciones sobre cronograma, alcance y procedimiento, y Amazon decidió patrocinar durante un año a través de GitHub Sponsors
- El patrocinio cubría 40 horas al mes combinando ingeniería de releases de FreeBSD y desarrollo de FreeBSD/EC2
- Se explicó que no era realista patrocinar solo una de las dos tareas porque ambas tienen dependencias entre sí
- La dedicación real subió a un promedio de unas 50 horas mensuales
- En promedio fueron 20 horas para temas exclusivos de EC2, 20 horas para releases de FreeBSD y 10 horas para otras tareas relacionadas con ingeniería de releases, aunque hubo bastante variación entre meses
Operación de releases trimestrales y mejoras de build
- Siguiendo el calendario de releases trimestrales de FreeBSD anunciado en julio de 2024, durante un año se gestionaron 4 releases
- FreeBSD 13.4: septiembre de 2024
- FreeBSD 14.2: diciembre de 2024
- FreeBSD 13.5: marzo de 2025
- FreeBSD 14.3: previsto para lanzarse el 10 de junio de 2025
- Cada release incluyó impulsar merges de código, aprobar o rechazar solicitudes de merge, coordinar con otros equipos, construir y probar imágenes, redactar anuncios y corregir problemas en los builds del release
- Por lo general se construyen 3 Beta, 1 Release Candidate y el Release final
- La mayor parte del trabajo se concentra en el mes previo al release, es decir, el segundo mes de cada trimestre, el “Beta Month”
- FreeBSD 13.5 tomó 33.5 horas y FreeBSD 14.2 tomó 79 horas
- A medida que una rama estable madura, tienden a reducirse los elementos que se rompen, y también la carga de trabajo del release
- No se llevó seguimiento de FreeBSD 14.1, pero se estima que la ingeniería de releases habría requerido cerca de 100 horas, y es probable que FreeBSD 15.0 requiera mucho más
- En la ingeniería de releases general también se avanzó en la paralelización de builds de releases
- A medida que aumentó la cantidad de AMI de EC2, el tiempo de instalar FreeBSD en imágenes de VM pasó a representar una parte importante, más que el build en sí
- Se paralelizó el código de release, pero aparecieron fallos esporádicos de build, y como un build completo tardaba unas 24 horas, era difícil aislar la causa
- La causa final fue una sola línea faltante en un Makefile: había que crear un directorio antes de instalar archivos
- Después de corregirlo, el build de release bajó de unas 22 horas a unas 13 horas, y eso también permitió ampliar los flavour de AMI de EC2 que se habían venido postergando por el tiempo de build
- Los problemas de reproducibilidad de builds comenzaron a verificarse de forma periódica usando EC2
- Durante las pruebas de imágenes snapshot semanales, se lanza una instancia EC2 para que construya sus propias AMI
- Luego se comparan las imágenes de disco generadas con las originales usando diffoscope
- Estas pruebas regulares permitieron encontrar varios problemas; algunos se corrigieron directamente y otros se derivaron a otros desarrolladores
Manejo de energía en Graviton y hotplug en FreeBSD/EC2
- Las funciones principales que Amazon pidió como prioridad en FreeBSD/EC2 fueron un power driver para instancias AWS Graviton y el hotplug de dispositivos
- El driver de energía para Graviton maneja la vía por la que la API de EC2 notifica al sistema operativo que debe apagarse
- Sin esta función, FreeBSD ignora la señal de apagado y, tras unos minutos, EC2 corta la energía virtual por timeout
- El “botón de encendido” en sistemas Graviton es un pin GPIO, y los detalles están en el objeto ACPI
_AEI - Se añadió código para localizar esa información en ACPI y pasar la configuración al driver del controlador GPIO PL061
- Cuando el pin GPIO se asserta, el controlador genera una interrupción, ocurre un evento ACPI de “power button” y eso lleva al apagado del sistema
- Las tablas ACPI que entrega EC2 indican que ese pin GPIO debe configurarse como “Pull Up”, pero el controlador PL061 no tiene resistencias pullup/pulldown
- Linux ignora silenciosamente el fallo de configuración, por lo que el problema no se hacía visible
- FreeBSD desactivaba el dispositivo después del fallo de configuración
- Es probable que en el futuro se corrija el bug de EC2 en sistemas Graviton, pero por ahora se agregó el quirk
ACPI_Q_AEI_NOPULLen las AMI de FreeBSD/EC2 para ignorar el flag GPIO PullUp del objeto_AEI
- El hotplug, en especial el hot unplug, requirió más trabajo porque se superponían problemas distintos en varios tipos de instancias EC2
- Algunos sistemas Graviton tenían una fuga de reservas de IRQ virtuales durante PCI attach, y después de conectar y desconectar un volumen EBS 67 veces se agotaban las IRQ y el kernel de FreeBSD entraba en panic
- La causa era el código heredado de ruteo de interrupciones PCI, y se añadió una configuración del boot loader para desactivar ese código en EC2
- Algunos sistemas Graviton usaban el estado de energía del dispositivo PCI como señal para decidir si el sistema operativo ya había terminado de usar el dispositivo y estaba listo para eject
- Esto se considera un bug de EC2, y por ahora se usa el quirk
ACPI_Q_CLEAR_PME_ON_DETACHpara cambiar algunos bits del registro de administración de energía PCI antes del eject
- Esto se considera un bug de EC2, y por ahora se usa el quirk
- En x86 y Graviton de instancias EC2 de generación reciente, el driver
nvmede FreeBSD provocaba un panic después de un unplug de PCIe- Este problema se remitió al mantenedor del driver
nvme
- Este problema se remitió al mantenedor del driver
- En algunas instancias EC2 x86 y Graviton, después de eject quedaban dispositivos “fantasma” en el bus PCI que impedían conectar nuevos dispositivos
- El firmware Nitro gestionaba de forma asíncrona la administración del bus PCI y la de los dispositivos PCI, de modo que existía una ventana de algunos ms en la que el dispositivo ya había sido unplugged pero el bus PCI todavía reportaba que seguía presente
- Linux reescanea periódicamente el bus y por lo general pierde esa carrera, pero FreeBSD volvía a escanear el bus PCI inmediatamente después del detach, por lo que era más frecuente que viera el fantasma
- Actualmente se usa el quirk
ACPI_Q_DELAY_BEFORE_EJECT_RESCANpara añadir un retraso de 10 ms antes del reescaneo del bus PCI tras la señal de eject
- Algunos sistemas Graviton tenían una fuga de reservas de IRQ virtuales durante PCI attach, y después de conectar y desconectar un volumen EBS 67 veces se agotaban las IRQ y el kernel de FreeBSD entraba en panic
- PCIe exige una espera de 5 segundos después de presionar el botón “attention” para solicitar el eject del dispositivo, y una segunda pulsación cancela la solicitud de eject
- En EC2 no hay una persona presionando un botón físico, y tampoco existe un mecanismo para volver a presionar un botón virtual, así que ese retraso es innecesario
- Se añadió un tunable del boot loader para fijar el timeout en 0 dentro de EC2
- Con un script de pruebas de hotplug se puede lanzar una instancia EC2 y, usando la API de EC2, conectar y desconectar repetidamente volúmenes EBS para comprobar que FreeBSD soporta 300 ciclos consecutivos de attach/detach
- Si en el futuro se obtiene acceso anticipado a tipos de instancia EC2, esto podría usarse para verificar el comportamiento de hotplug
Seguimiento de regresiones de rendimiento de arranque y expansión de AMI
- Además de las dos tareas prioritarias de Amazon, alrededor de la mitad del tiempo dedicado a EC2 se usó en otros problemas de FreeBSD/EC2
- A fines de 2023 y principios de 2024, las instancias FreeBSD/EC2 a veces arrancaban mucho más lento de lo esperado, y en las pruebas semanales de snapshots hubo que aumentar el tiempo de espera antes de intentar conectarse por SSH después de lanzar la instancia
- Para tratar el problema de rendimiento, se hicieron benchmarks del tiempo de arranque de builds semanales de AMI de EC2 desde 2018
- En el proceso se lanzaron más de 10 mil instancias EC2
- Se empezaron a generar las gráficas de rendimiento de arranque de FreeBSD
- La recopilación de nuevos datos y la actualización de las gráficas se incorporaron al proceso de pruebas semanales de snapshots
- Se detectaron y corrigieron varias causas de demoras de arranque
- Desde la primera semana de 2024, el arranque de FreeBSD se volvió unas 3 veces más lento, y se rastreó la causa hasta un commit que aumentó el tamaño del disco raíz de 5 GB a 6 GB
- Tras revisar el tema del lado de Amazon, se confirmó que aumentar el disco raíz a 8 GB recuperaba el rendimiento anterior
- En la familia Graviton 2, un problema con el sembrado de entropía del kernel hacía más lento el arranque
- El kernel de FreeBSD detiene el arranque si no hay suficiente entropía para generar números aleatorios seguros, hasta reunir más entropía
- Ya existía código para recibir un seed seguro desde el firmware Nitro a través del boot loader EFI, pero no se ejecutaba en EC2, y en Graviton 2 pedir 2048 bytes era muy lento
- La solicitud que estaba en el código Lua del menú de arranque se movió al lugar correcto del Lua del boot loader para que se ejecute independientemente de si el menú está desactivado
- Además, se cambió para tomar 64 bytes de entropía EFI y expandirlos con PBKDF2 al tamaño de entrada de 2048 bytes que esperaba la API, reduciendo el tiempo de arranque de FreeBSD
arm64/base/UFSde unos 25 segundos a unos 8 segundos
- Las imágenes ZFS arrancaban más lento que UFS, y la magnitud de la demora dependía no del tamaño del disco sino de la cantidad de datos en él
makefsponía todo en un solo grupo de transacciones, y al hacer attach de ZFS se recorría y validaba el grupo de transacciones más reciente, leyendo y procesando todos los metadatos de archivos del disco- Mark Johnston lo resolvió haciendo que el filesystem registrara un grupo de transacciones más alto, para que ese grupo único no se considerara “reciente”
- El tiempo de arranque de imágenes ZFS bajó de unos 22 segundos a unos 11 segundos
- En diciembre de 2024 se detectó rápidamente un problema de arranque después de agregar soporte IPv6 al port
net/aws-ec2-imdsv2-get- Este port ofrece una interfaz de línea de comandos para el EC2 Instance MetaData Service
- Primero intentaba IPv6, pero la configuración predeterminada de instancias IMDS era solo IPv4, y además se mantenía el timeout TCP predeterminado de 75 segundos
- Tras corregirlo, ahora se intenta primero con IPv4 y el timeout se redujo a 100 ms
- Desde la primera semana de 2024, el arranque de FreeBSD se volvió unas 3 veces más lento, y se rastreó la causa hasta un commit que aumentó el tamaño del disco raíz de 5 GB a 6 GB
- También se ampliaron los flavour de AMI de FreeBSD
- Antes solo existían
baseycloud-init - La AMI
smallelimina debug symbols, LLDB, bibliotecas de 32 bits, pruebas de FreeBSD, Amazon SSM Agent y AWS CLI, reduciendo el uso de disco de aproximadamente 5 GB a aproximadamente 1 GB - La AMI
builderofrece FreeBSD AMI Builder AMIs para que los usuarios puedan crear fácilmente AMI personalizadas de FreeBSD
- Antes solo existían
- Con la combinación de 4 flavour de AMI, 2 filesystems, 2 arquitecturas y 3 versiones de FreeBSD, aumentó la cantidad de builds snapshot semanales, por lo que se limpiaron imágenes antiguas y los snapshots EBS asociados
- La cuenta AWS de ingeniería de releases de FreeBSD recibe el patrocinio de Amazon, pero ese almacenamiento igual tiene un costo para alguien
- Se escribió un script de shell que permitió eliminar 336 TB de snapshots EBS
Trabajo pendiente y limitaciones tras el fin del patrocinio
- Además de los grandes proyectos, siguieron apareciendo muchas tareas pequeñas
- Corregir roturas de build detectadas en los builds snapshot semanales
- Revisar parches del driver ENA
- Ayudar a Dave Cottlehuber a agregar la función para construir OCI Container y subirlo al repositorio
- Mejorar la herramienta
bsdec2-image-uploadpara manejar con más suavidad errores internos de AWS - Reportar un problema de seguridad de AWS encontrado por casualidad
- Incluso después de terminar el patrocinio, continuarán los roles de líder de ingeniería de releases de FreeBSD y de mantenedor de la plataforma FreeBSD/EC2
- FreeBSD 15.0 está previsto para diciembre
- En 2026 deberían llegar 14.4, 15.1, 14.5 y 15.2
- Con menos tiempo disponible, será más difícil corregir directamente problemas justo antes de un release
- Las funciones que lleguen tarde tendrán más probabilidades de ser eliminadas del release en lugar de corregirse a tiempo
- Que FreeBSD pudiera incluir OCI Containers desde 14.2 fue posible porque el tiempo patrocinado permitió confirmar que todas las piezas necesarias entraran completas
- Del lado de EC2, ahora existen pruebas de regresión de rendimiento de arranque, así que hay más probabilidades de detectar ese tipo de problemas, pero la lista de funciones por implementar podría estancarse sin tiempo adicional
- Expansión automática del filesystem al ampliar volúmenes EBS
- Mejoras en la configuración automática de múltiples interfaces de red y del hotplug de interfaces de red
- AMI rolling “pre-patched”
- Un sitio web para generar archivos EC2 user-data para instalar paquetes, ejecutar daemons y más
- Retomar el trabajo en FreeBSD/Firecracker y convertirlo en una plataforma soportada
- El patrocinio de Amazon fue una oportunidad mucho mayor que la que recibe la mayoría de los desarrolladores de open source, y junto con la tristeza de que termine queda el agradecimiento por todo lo que se pudo lograr
1 comentarios
Opiniones en Hacker News
Qué bueno. Desde hoy agregamos FreeBSD a la página de descargas de ziglang.org, para que los usuarios de FreeBSD puedan obtener builds de la rama master generados automáticamente en CI.
Ahora también se admite como objetivo de cross-compilation de primera clase, incluyendo el enlace con libc, así que cosas como
zig cc -o hello hello.c -target riscv64-freebsdtambién son posibles.Si hay dependencias de C/C++, se pueden incorporar y compilar con el sistema de build de Zig, así que creo que incluso proyectos bastante complejos podrían compilarse fácilmente para FreeBSD mediante cross-compilation. Espero que esto ayude a que más proyectos agreguen soporte para FreeBSD y pruebas en CI.
Sería bueno tener un reemplazo de C reconocido oficialmente.
Hay varias partes interesantes aquí.
“Desde la primera semana de 2024, el proceso de arranque de FreeBSD de pronto se volvió unas 3 veces más lento. Al hacer una búsqueda binaria entre commits, la causa resultó ser un commit que aumentaba el tamaño del disco raíz de 5 GB a 6 GB. ¿Por qué pasó eso? Al preguntarles a conocidos en Amazon, la respuesta estuvo en algún punto entre ‘magia’ y ‘realmente no quieres saberlo’; lo importante fue que, al aumentar el disco raíz a 8 GB, el rendimiento volvió al nivel anterior”.
No sé si eso está relacionado con el precipicio de rendimiento observado.
También se está haciendo mucho trabajo del lado de laptops, y leí que la BSD Foundation invirtió 750 mil dólares en eso.
Incluye implementaciones como el estado de suspensión S0ix, y el proyecto se puede ver aquí: https://github.com/FreeBSDFoundation/proj-laptop
Siento un enorme respeto por cperciva.
No sé cómo logra hacer todo esto junto con Tarsnap.
Para ser justos, parte del tiempo que puse aquí salió de Tarsnap, pero mucho menos de lo que uno podría pensar.
Esperaba que Amazon gastara y contribuyera más, pero parece que básicamente solo quiere pagar por el soporte mínimo de FreeBSD.
Amazon ni siquiera aparece en la lista de patrocinadores de FreeBSD [1], Google patrocinó apenas con 9 mil dólares el año pasado y Apple tampoco está. Microsoft al menos aparece en la lista, eso hay que reconocerlo. Meta/Facebook también falta.
Estas empresas usan FreeBSD y OpenBSD y siguen beneficiándose de ellos, así que básicamente esperaba que patrocinaran todos los años.
[1] https://freebsdfoundation.org/our-donors/donors/?donationYea...
Por ejemplo, el dinero que me pagaron a mí no pasó por la Foundation. Si tuviera que estimar, del desarrollo de FreeBSD financiado con fondos corporativos, el desarrollo apoyado por la Foundation probablemente sea alrededor del 10%.
Ese 10% es especialmente importante porque puede enfocarse en “lo que FreeBSD necesita” y no en “lo que necesita la empresa X”, pero sigue siendo una porción pequeña.
Primero, solo muestra una instantánea de las donaciones a la Foundation en un año específico, así que naturalmente no refleja el historial de donaciones.
Segundo, tampoco muestra las contribuciones de desarrollo. Ese tipo de información suele poder verse resumida en las notas de cada release [1].
[1] https://www.freebsd.org/releases/
Tampoco se me ocurre ningún servicio de Microsoft, en la nube o no, que corra sobre *BSD.
Quería usar FreeBSD como gateway/firewall/DNS/servidor DHCP en casa, pero parece que no había driver para mi NIC 10GbE, así que al final elegí Nix.
Hace mucho usé FreeBSD como workstation y fue una experiencia bastante memorable. Me alegra ver que todavía sigue avanzando de forma constante.
Realtek parece romperse bajo carga aunque los ingenieros de FreeBSD que mantienen el driver se esfuercen mucho. No me estoy quejando; respeto su trabajo.
Es un precio pequeño a pagar, y me evita tener que instalar un sistema operativo menos estable.
Recuerdo que, por la época de FreeBSD 7 u 8, hubo un tiempo en que los drivers de FreeBSD para cosas como las tarjetas Wi‑Fi Atheros eran mejores que los de Linux.
Preferí FreeBSD hasta alrededor de 2021, pero eso cambió cuando se volvieron comunes las computadoras con distintos tipos de núcleos de CPU mezclados. Primero compré una RockPro64 con 2 núcleos big y 4 núcleos little, y después compré un Intel Alder Lake.
Según entiendo, el scheduler de FreeBSD todavía no maneja bien esas configuraciones, así que parece llevar el sistema al mínimo común denominador de los núcleos más lentos.
Por curiosidad, ¿quiénes son los principales usuarios de FreeBSD/EC2?
De verdad me gustaría saber quién usa FreeBSD en EC2.
Es un artículo que muestra muy bien cómo funciona el patrocinio open source por parte de las empresas.
¿Alguien que use FreeBSD podría explicar qué nicho ocupa FreeBSD dentro del espacio Unix? ¿Por qué FreeBSD y no OpenBSD o NetBSD, que son más simples y consistentes?
Si la respuesta es el soporte para ZFS, drivers de Nvidia, ELF y cosas así, ¿por qué no Linux? Entiendo bien los problemas de GNU, pero ¿también hay problemas con algo como Musl Void?
De verdad me da curiosidad. Para mí FreeBSD existe como una especie de zona en sombras: no logro identificar con precisión la identidad central que lo mantiene en marcha, pero sé que está en algún lado.
Cada servicio se ejecutaba en su propio jail para aislamiento, y un solo servidor, ni siquiera muy potente, podía correr todos los servicios, así que era enormemente eficiente en costos.
En algún momento hicimos una migración a la nube para una configuración híbrida, y al mezclar Linux (k8s) con FreeBSD los costos se dispararon. En un datacenter tienes que comprar y reemplazar discos tú mismo, responder a situaciones como incendios, y está la desventaja de estar en un solo país; AWS, en cambio, ofrece multirregión y muchas funciones buenas, y cobra en consecuencia.
No aprovechábamos ZFS de forma extremadamente intensiva, pero una vez nos salvó en grande cuando alguien eliminó por error una tabla en la base de datos de producción: hicimos rollback de inmediato al snapshot de ZFS anterior. Hubo una pequeña pérdida de datos, pero para esa aplicación el tiempo de actividad era más importante, así que no fue un gran problema. Recuerdo que también usábamos ZFS para backups.
Usé dtrace algunas veces para resolver problemas en producción, y cuando introdujimos Linux en el conjunto de servidores FreeBSD, cada equipo terminó eligiendo naturalmente una distribución distinta, convirtiéndolo en una especie de zoológico. Si usas FreeBSD en servidores, solo hay una variante.
Sigo usando y apreciando ambos, pero realmente me gusta que FreeBSD sea una forma integrada de kernel y sistema operativo.
Históricamente, FreeBSD priorizó las CPU Intel, NetBSD fue más fuerte en portabilidad, y aunque FreeBSD también tenía una seguridad sólida, OpenBSD se enfocó más en seguridad.
El soporte de ZFS de FreeBSD realmente cambia las reglas del juego. Según entiendo, Nvidia recién hace poco ofrece drivers nativos para FreeBSD, y durante mucho tiempo se necesitó la compatibilidad de FreeBSD con el kernel de Linux.
En otras palabras, FreeBSD combina bien las funciones que ofrecen los otros BSD y, al mismo tiempo, fue increíblemente estable en la plataforma de hardware que uso principalmente.
NetBSD compite por portabilidad, y no me da la impresión de que dedique mucho tiempo a mantener alto el throughput de red.
En general, todos los BSD cambian mucho menos y, aunque eso tiene pros y contras, me parecen mejores como plataformas objetivo para integración.
La lista de software también es mucho más grande, y puede usarse como sistema operativo moderno de escritorio para el día a día. Es difícil decir lo mismo de los otros dos.
Si preguntas por qué no Linux: porque no quiero Linux. Está demasiado aplastado por intereses corporativos.