Risposte interessanti finora. Condividerò la mia prospettiva non comune su questo: Ho lavorato su un file system di journaling (per sistemi UNIX) che è stato commercializzato con successo poco prima che Windows NT 3.1 uscisse. Ho iniziato a lavorare su Windows NT 3.1 mentre era ancora in Beta e ho imparato molto sul funzionamento interno di Windows, in particolare per quanto riguarda i file system. Ho incontrato l'attuale responsabile dello sviluppo di NTFS nel 1996 (prima che fosse in Microsoft, in effetti) quando ha seguito il mio corso "Developing File Systems for Windows" (insieme ad altre 52 persone). L'ho rivisto il mese scorso e, come al solito, siamo finiti a parlare di file system.
I file system tendono ad avere una vita molto lunga come software perché si occupano di gestire dati persistenti. Hanno forti requisiti di affidabilità: quando il vostro browser web finisce la memoria e si blocca, riavviate il browser web e il problema sparisce, ma quando il vostro file system finisce la memoria e si blocca, riavviate il computer e scoprite quali dati sono stati persi. I problemi possono essere persistenti e ricorrenti.
Il progetto NTFS era all'avanguardia nello sviluppo dei file system all'epoca. Avevano tentato di costruire i loro file system in stile micro-kernel, in modo che i file system fossero eseguiti in processi separati, anche se alla fine hanno abbandonato questo approccio perché non si comportava sufficientemente bene sui sistemi che avevano a disposizione in quel momento. Le vestigia di questo rimangono oggi (hanno routine Fsp o "file system process" per gestire le operazioni di file system in coda). Dave Cutler, l'architetto di Windows NT, è stato a lungo un sostenitore del microkernel (è co-autore di un documento SOSP del 1973 che descrive un microkernel prima che questa fosse la terminologia comune). NTFS usava un giornale transazionale in scrittura per fornire resilienza di fronte ai crash di sistema, presumibilmente basato sul lavoro del file system Cedar diversi anni prima. Incorporava ACL a grana fine (ma lo stesso faceva il file system su cui lavoravo - in effetti, quando vidi la loro implementazione ACL ero abbastanza a mio agio con essa perché sembrava che entrambi avessimo seguito le stesse identiche bozze di sicurezza POSIX.)
Aveva più unità disparate di dati di file all'interno di un singolo file ("streams"), qualcosa che avevamo implementato ma usando un nome diverso e con maggiori restrizioni. Aveva Extended Attributes (da OS/2). Era un file system insensibile alle maiuscole e alle minuscole (richiesto per la conformità a POSIX.1). Usava estensioni per descrivere i file (simile al file system di Veritas dell'epoca). Una decisione innovativa era quella di duplicare le informazioni sugli attributi dei file nelle loro directory, il che rendeva l'enumerazione delle directory con gli attributi molto veloce.
Internamente, usava (e usa ancora) una tabella indice piatta abbastanza standard (poiché la maggior parte dei file system gerarchici sono costruiti sopra una tabella piatta, con la gerarchia costruita logicamente sopra lo spazio dei nomi piatto).
Supportava i file "in linea" (quindi i dati sono memorizzati nel record MFT, che è l'equivalente dell'inode sul disco). Utilizzava nativamente nomi UNICODE a 16 bit per quasi tutto (l'unica eccezione sono i nomi degli attributi estesi, che sono stringhe ASCII a 8 bit.)
Nel tempo sono state aggiunte delle caratteristiche: supporto alla compressione, supporto alla crittografia, ACL condivise (quindi c'è una tabella di ACL piuttosto che copiarle in ogni file separato, una mossa per risparmiare spazio.)
Il file system NTFS fornisce un'interfaccia per l'archiviazione transazionale ai programmi applicativi, in modo da poter fare cose come "rinominare questo insieme di file atomicamente" - e questo non ha richiesto di cambiare il formato su disco per farlo. Il registro di Windows, che è un database di configurazione, dipende dalle transazioni NTFS per implementare la propria interfaccia transazionale (si noti che non deve esserlo, era solo più facile data la disponibilità di quelle transazioni). Certo si può costruire il proprio monitor transazionale, ma quando il file system lo fornisce si possono anche scrivere le operazioni del file system per essere transazionali.
Nei tardi anni '80 e nei primi anni '90 la deframmentazione era generalmente fatta tramite programmi esterni, non dal file system. Farlo nel file system è simile a spostare funzionalità complesse dalla modalità utente alla modalità kernel, qualcosa che di solito viene scoraggiato in quanto si cerca di limitare la complessità del livello kernel (poiché gli errori a livello kernel hanno conseguenze più gravi che a livello utente). Allo stesso modo, non vorrei nemmeno che il mio file system facesse direttamente l'accelerazione del caricamento del programma - lasciatelo in un'applicazione e usate il file system per registrare le informazioni rilevanti. Fai in modo che il caricatore del programma usi quelle informazioni per rendere le cose più veloci.
In Windows Vista, NTFS ha introdotto le operazioni di riparazione del file system online (ho ridacchiato quando ho sentito qualcuno a FAST 2018 affermare che il loro file system è stato il primo a farlo, più di 10 anni dopo che il team NTFS lo ha implementato). Nel corso del tempo hanno ulteriormente migliorato questa capacità di riparare i danni minori online, e i loro strumenti di ripristino offline, nelle rare volte in cui è necessario eseguirli, sono diventati abili nel riparare i danni.
Oggi in Windows 10, NTFS supporta l'archiviazione DAX, che è certamente all'avanguardia (non posso nemmeno ottenere facilmente la memoria della classe di archiviazione per la mia ricerca sui file system,) eppure continua a fornire un comportamento solido come una roccia. È attivamente mantenuto, quindi so che se segnalo un bug verrà risolto (e ho segnalato e fatto risolvere bug in NTFS diverse volte nel corso degli anni.)
L'ultima volta che ho controllato, Windows non ha una cache di ricerca dei nomi di directory (DNLC) che rallenta le prestazioni di apertura. Nel mio lavoro sui file system su Windows in passato, usavo una cache di ricerca veloce per questo - una cache a voce singola per CPU dimostrava un tasso di successo del ~80% all'epoca a causa della discrepanza tra le API native di Win32 e NT (l'API nativa è dominata da operazioni di gestione, l'API Win32 è dominata da operazioni sui nomi). Questo non è un problema di file system quanto un problema di sistema operativo e nel corso degli anni il numero di API basate sui nomi a livello nativo sono aumentate e anche il numero di API basate su handle a livello Win32 sono aumentate.
Le prestazioni dei file system sono spesso una funzione dell'implementazione, non della struttura su disco. I file system progettati per le unità disco devono essere sintonizzati/modificati per funzionare con gli SSD (per esempio). Allo stesso modo cose come la cache di pagina diventano un freno alle prestazioni quando si accede direttamente alla memoria.
Per essere un progetto vecchio di 28 anni, direi che NTFS ha retto piuttosto bene. Possiamo fare meglio ora usando l'hardware moderno, i progressi nella nostra comprensione dei fallimenti e l'aumento di 10.000 volte della dimensione del nostro storage e delle nostre memorie? Sarei piuttosto sorpreso se non ci riuscissimo. Ma ci vorranno dieci anni o più prima che il file system che costruiamo oggi per l'hardware di oggi sia "pronto per la prima serata". Quindi se volete costruire un nuovo file system, non pianificate per l'hardware di oggi. Pianificate per l'hardware che sarà disponibile tra 10 anni.
In fondo: NTFS rimane un eccellente esempio di progettazione di file system con journaling degli anni '80, bilanciando caratteristiche e prestazioni.