Cattive prestazioni NTFS

Perché le prestazioni NTFS sono così scadenti rispetto, ad esempio, a Linux / ext3? Molto spesso lo vedo quando eseguo il check out di alberi di origine (di grandi dimensioni) da Subversion. Il checkout richiede circa 10-15 minuti su NTFS, mentre il checkout corrispondente su Linux (su hardware quasi identico) richiede un ordine di grandezza più veloce (1 - 1,5 minuti).

Forse questo è specifico per la gestione di molti file di piccole dimensioni e NTFS è meglio quando si tratta di file di grandi dimensioni, ma perché dovrebbe essere? Il miglioramento delle prestazioni NTFS per file di piccole dimensioni non sarebbe estremamente vantaggioso per le prestazioni di Windows in generale?

EDIT: Questo non è inteso come una domanda infiammatoria "NTFS succhia rispetto a ext3"; Sono sinceramente interessato al perché NTFS si comporta male in alcuni casi. È solo un cattivo design (di cui dubito) o ci sono altri problemi che entrano in gioco?

NTFS ha questa cosa chiamata tabella dei file master . Sembra davvero bello quando lo leggi.

Si può vedere che ext3 funziona bene fino a circa il 95% dell'uso del disco, mentre l'esistenza di MFT significa che NTFS non vuole davvero che tu usi più del 90% del tuo disco. Ma suppongo che non sia un tuo problema e che il tuo problema sia con le numerose operazioni su molti file di piccole dimensioni.

Una delle differenze qui è ciò che accade quando si crea un piccolo file. Se un file è più piccolo di una dimensione del blocco, non viene scritto nel suo blocco ma piuttosto viene archiviato nella MFT. Questo è utile se il file rimane esattamente com'era quando è stato creato. In pratica, tuttavia, significa che quando svn tocca un file per crearlo, quindi si aggiunge a quel file, lo rimuove o lo modifica semplicemente non abbastanza da spostarlo nel suo blocco, l'operazione è piuttosto lenta. Inoltre, la sola lettura di molti file di piccole dimensioni mette in rilievo la MFT in cui risiedono tutti, con multipli per blocco. Perché dovrebbe farlo? Evita preventivamente la frammentazione e usa più blocchi in modo più efficace, e in generale è una buona cosa.

In ext2 e 3, al contrario, i blocchi di file per ogni file vengono archiviati accanto al punto in cui si trovano i metadati della directory per la directory in cui si trovano (se possibile, se il disco non è frammentato e si dispone di circa il 20% di spazio libero). Questo significa che mentre svn sta aprendo le directory, un certo numero di blocchi viene praticamente memorizzato nella cache gratuitamente in quella cache da 16 MB sul tuo disco, e poi di nuovo nella cache del kernel. Tali file potrebbero includere il file .svn e i file di revisione per l'ultimo aggiornamento. Questo è utile poiché è probabile che alcuni dei file che svn sta guardando in seguito. NTFS non riesce a fare ciò, anche se gran parte della MFT dovrebbe essere memorizzata nella cache del sistema, potrebbero non essere le parti che vorrete dopo.

Bene, il tuo problema particolare è perché

1. Subversion stessa proviene dal mondo UNIX, pertanto la versione Windows assume caratteristiche prestazionali simili.
2. Le prestazioni NTFS non sono davvero eccezionali con milioni di piccoli file.

Quello che stai vedendo è semplicemente un artefatto di qualcosa progettato per un particolare sistema operativo con ipotesi prestazionali su quei sistemi operativi. Questo di solito si guasta male, se portato su altri sistemi. Altri esempi potrebbero essere il fork e il threading. Sui Mi piace di UNIX il modo tradizionale di parallelizzare qualcosa è solo quello di generare un altro processo. Su Windows, dove l'avvio dei processi richiede almeno cinque volte di più, questa è una pessima idea.

In generale, non puoi semplicemente prendere qualsiasi artefatto di un determinato sistema operativo da concedere su qualsiasi altro con un'architettura molto diversa. Inoltre, non dimenticare che NTFS ha molte funzionalità di file system che erano assenti nei file system UNIX ampiamente utilizzate a quel punto, come journaling e ACL. Queste cose hanno un costo.

Un giorno, quando avrò un sacco di tempo libero, stavo programmando di scrivere un modulo di filesystem SVN che sfrutti le funzionalità che hai su NTFS, come il supporto delle transazioni (dovrebbe eliminare il "problema di milioni di piccoli file") e dati alternativi flussi (dovrebbe eliminare la necessità della .svndirectory separata ). Sarebbe una bella cosa avere, ma dubito che gli sviluppatori SVN riusciranno a implementare queste cose nel prossimo futuro.

Nota a margine: un singolo aggiornamento su un grande repository SVN che sto usando ha richiesto circa 250.000 operazioni sui file. Qualche piccola voce mi dice che questo è davvero molto per 24 file che sono cambiati ...

Ecco le informazioni di Microsoft su come funziona NTFS. Potrebbe essere eccessivo per quello che stai cercando, ma studiarlo potrebbe far luce su quali scenari NTFS ha problemi.