Interesantes respuestas hasta ahora. Voy a compartir mi propia perspectiva poco común en esto: Trabajé en un sistema de archivos de diario (para sistemas UNIX) que se comercializó con éxito poco antes de que se lanzara Windows NT 3.1. Empecé a trabajar en Windows NT 3.1 cuando todavía estaba en fase Beta y aprendí mucho sobre el funcionamiento interno de Windows, especialmente en lo que respecta a los sistemas de archivos. Conocí al actual jefe de desarrollo de NTFS en 1996 (antes de que estuviera en Microsoft, de hecho) cuando asistió a mi clase de «Desarrollo de sistemas de archivos para Windows» (junto con otras 52 personas). Le volví a ver el mes pasado y, como siempre, acabamos hablando de sistemas de archivos.
Los sistemas de archivos suelen tener una vida útil muy larga como software porque se ocupan de gestionar datos persistentes. Tienen fuertes requisitos de fiabilidad: cuando tu navegador web se queda sin memoria y se bloquea, reinicias tu navegador web y el problema desaparece, pero cuando tu sistema de archivos se queda sin memoria y se bloquea, reinicias tu ordenador y averiguas qué datos se han perdido. Los problemas pueden ser persistentes y recurrentes.
El diseño de NTFS estaba en la vanguardia del desarrollo de sistemas de archivos en ese momento. Habían intentado construir sus sistemas de archivos al estilo del micro-núcleo, de modo que los sistemas de archivos se ejecutaban en procesos separados, aunque finalmente abandonaron ese enfoque porque no funcionaba lo suficientemente bien en los sistemas que tenían disponibles en ese momento. Los vestigios de esto permanecen hoy en día (tienen rutinas Fsp o «file system process» para manejar las operaciones del sistema de archivos en cola). Dave Cutler, el arquitecto de Windows NT, fue durante mucho tiempo un defensor del micronúcleo (es coautor de un documento de la SOSP de 1973 que describe un micronúcleo antes de que esa fuera la terminología común). NTFS utilizaba un diario transaccional de escritura anticipada para proporcionar resistencia frente a las caídas del sistema, presumiblemente basado en el trabajo del sistema de archivos Cedar de varios años antes. Incorporaba ACLs de grano fino (pero también lo hacía el sistema de archivos en el que yo trabajaba – de hecho, cuando vi su implementación de ACL me sentí bastante cómodo con ella porque parecía que ambos habíamos estado siguiendo exactamente los mismos borradores de seguridad POSIX.)
Tenía múltiples unidades dispares de datos de archivo dentro de un único archivo («streams»), algo que habíamos implementado pero usando un nombre diferente y con mayores restricciones. Tenía atributos extendidos (de OS/2). Era un sistema de archivos que no distinguía entre mayúsculas y minúsculas (necesario para cumplir con POSIX.1). Utilizaba extensiones para describir los archivos (similar al sistema de archivos de Veritas en ese momento). Una decisión novedosa fue duplicar la información de los atributos de los archivos en sus directorios, lo que hizo que la enumeración de directorios con atributos fuera muy rápida.
Internamente, utilizaba (y aún utiliza) una tabla de índices plana bastante estándar (ya que la mayoría de los sistemas de archivos jerárquicos se construyen sobre una tabla plana, con la jerarquía construida lógicamente sobre el espacio de nombres plano).
Soportaba archivos «inline» (por lo que los datos se almacenan en el registro MFT, que es el equivalente al inodo en el disco). Utilizaba de forma nativa nombres UNICODE de 16 bits para casi todo (la única excepción son los nombres de atributos extendidos, que son cadenas ASCII de 8 bits.)
Con el tiempo, han añadido características: soporte de compresión, soporte de encriptación, ACLs compartidas (por lo que hay una tabla de ACLs en lugar de copiarlas en cada archivo por separado, una medida de ahorro de espacio.)
El sistema de archivos NTFS proporciona una interfaz para el almacenamiento transaccional a los programas de aplicación, de modo que se pueden hacer cosas como «renombrar este conjunto de archivos atómicamente» – y eso no requería que cambiaran el formato en el disco para hacerlo. El Registro de Windows, que es una base de datos de configuración, depende de las transacciones de NTFS para implementar su propia interfaz transaccional (nótese que no tiene por qué serlo, simplemente era más fácil dada la disponibilidad de esas transacciones). Seguro que puedes construir tu propio monitor transaccional, pero cuando el sistema de archivos lo proporciona también puedes programar tus operaciones del sistema de archivos para que sean transaccionales.
A finales de los 80 y principios de los 90 la desfragmentación se hacía generalmente a través de programas externos, no por el sistema de archivos. Hacerlo en el sistema de archivos es algo parecido a trasladar una funcionalidad compleja del modo usuario al modo kernel, algo que normalmente se desaconseja al intentar limitar la complejidad a nivel de kernel (ya que los errores a nivel de kernel tienen consecuencias más graves que a nivel de usuario). Del mismo modo, yo tampoco querría que mi sistema de archivos hiciera la aceleración de la carga de programas directamente – déjalo en una aplicación y usa el sistema de archivos para registrar la información relevante. Que el cargador de programas utilice esa información para hacer que las cosas se carguen más rápido.
En Windows Vista, NTFS introdujo las operaciones de reparación del sistema de archivos en línea (me reí cuando escuché a alguien en FAST 2018 afirmando que su sistema de archivos fue el primero en hacerlo, más de 10 años después de que el equipo de NTFS lo implementara). Con el tiempo han mejorado aún más esta capacidad de reparar daños menores en línea, y sus herramientas de recuperación fuera de línea, en las raras ocasiones en las que debes ejecutarlas, se han vuelto expertas en la reparación de daños.
Hoy en día, en Windows 10, NTFS admite el almacenamiento DAX, que es ciertamente vanguardista (ni siquiera puedo obtener fácilmente la memoria de clase de almacenamiento para mi propia investigación de sistemas de archivos,) sin embargo, continúa proporcionando un comportamiento sólido como una roca. Se mantiene de forma activa, así que sé que si informo de un error se solucionará (y he informado y he hecho que se solucionen errores en NTFS varias veces a lo largo de los años.)
La última vez que miré, Windows no tiene una caché de búsqueda de nombres de directorio (DNLC) que ralentiza el rendimiento de apertura. En mi propio trabajo de sistemas de archivos en Windows en el pasado, solía utilizar una caché de búsqueda rápida para esto – una caché de una sola entrada por CPU demostró una tasa de éxito de ~80% en el momento debido a la diferencia de la API nativa de Win32 a NT (la API nativa está dominada por las operaciones de manejo, la API de Win32 está dominada por las operaciones de nombre). Esto no es un problema del sistema de archivos sino del sistema operativo, y a lo largo de los años el número de APIs basadas en nombres a nivel nativo se ha incrementado y el número de APIs basadas en manejadores a nivel de Win32 también ha aumentado.
El rendimiento de los sistemas de archivos es a menudo una función de la implementación, no de la estructura en el disco. Los sistemas de archivos diseñados para unidades de disco necesitan ser ajustados/modificados para trabajar con SSDs (por ejemplo). Del mismo modo, cosas como la caché de páginas se convierten en un lastre para el rendimiento cuando se accede directamente a la memoria.
Para un diseño de hace 28 años, yo diría que NTFS ha aguantado bastante bien. ¿Podemos hacerlo mejor ahora usando el hardware moderno, los avances en nuestra comprensión de los fallos, y el aumento de 10.000 veces en el tamaño de nuestro almacenamiento y memorias? Me sorprendería bastante que no pudiéramos. Pero pasarán diez años o más antes de que el sistema de archivos que construyamos hoy en día para el hardware actual esté «listo para el momento estelar». Así que si quieres construir un nuevo sistema de archivos, no planees para el hardware de hoy. Planifique para el hardware que estará disponible dentro de 10 años.
En resumen: NTFS sigue siendo un excelente ejemplo de diseño de sistemas de archivos con registro en el diario de los años 80, equilibrando las características y el rendimiento.