Perché un disco Ext4 è molto più veloce di NTFS?

Ho avuto una situazione oggi in cui ho riavviato il mio computer e ha detto che dovevo controllare la coerenza del disco. Circa 10 minuti dopo (al "1%" completo), ho rinunciato e ho deciso di lasciarlo correre quando torno a casa.

Per fare un confronto, il mio computer di casa usa Ext4 per tutte le partizioni e i controlli del disco (che girano una volta alla settimana) richiedono solo un paio di secondi. Ricordo di aver letto che avere controlli rapidi del disco era una priorità, ma non so come potessero farlo.

Quindi, come fa Ext4 a eseguire i controlli del disco così velocemente? C'è qualche grande svolta nel fare questo dopo l'uscita di NTFS (~ 10 anni fa)?

Nota: il disco NTFS è ~ 300 GB e il disco Ext4 è ~ 500 GB. Entrambi sono circa la metà pieni.

Esistono due motivi principali per la differenza di prestazioni e due possibili motivi. Innanzitutto, i motivi principali:

Prestazioni migliorate di ext4 rispetto a NTFS

Vari benchmark hanno concluso che l'attuale file system ext4 può eseguire una varietà di operazioni di lettura / scrittura più velocemente di una partizione NTFS. Si noti che mentre questi test non sono indicativi delle prestazioni del mondo reale, possiamo estrapolare questi risultati e utilizzarli come uno dei motivi.

Per quanto riguarda il motivo per cui ext4 ha effettivamente prestazioni migliori, allora NTFS può essere attribuito a una grande varietà di ragioni. Ad esempio, ext4 supporta direttamente l'allocazione ritardata. Ancora una volta, tuttavia, i miglioramenti delle prestazioni dipendono strettamente dall'hardware utilizzato (e in alcuni casi possono essere totalmente negati).

Requisiti di controllo del filesystem ridotto

Il filesystem ext4 è anche in grado di eseguire controlli del file system più veloci rispetto ad altri filesystem journaling equivalenti (ad es. NTFS). Secondo la pagina di Wikipedia:

In ext4, i gruppi di blocchi non allocati e le sezioni della tabella degli inode sono contrassegnati come tali. Ciò consente a e2fsck di saltarli interamente su un controllo e riduce notevolmente il tempo necessario per controllare che un file system della dimensione ext4 sia costruito per supportare. Questa funzione è implementata nella versione 2.6.24 del kernel Linux.

E ora, i due possibili motivi:

Utilità di controllo del file system

Alcune applicazioni possono eseguire routine diverse sui filesystem per eseguire effettivamente il "controllo" dell'integrità. Questo può essere facilmente visto se si utilizza l' utility fsck impostata su Linux rispetto all'utilità chkdsk su Windows. Queste applicazioni sono scritte su diversi sistemi operativi per diversi file system. Il motivo per cui lo sollevo come possibile motivo è che le chiamate di sistema di basso livello in ciascun sistema operativo sono diverse e quindi potresti non essere in grado di confrontare direttamente i programmi di utilità utilizzando due diversi sistemi operativi.

Frammentazione del disco

Questo è facile da capire e ci aiuta anche a capire le differenze tra i file system. Mentre tutti i dati digitali contenuti in un file sono gli stessi, il modo in cui vengono archiviati sul disco rigido è molto diverso da file system a file system. La frammentazione dei file può ovviamente aumentare la velocità di accesso, attribuendo a una maggiore differenza di velocità.

Dalla mia comprensione ext4 cerca di scrivere dati nel più grande divario continuo di inode aperti dove attualmente non risiedono dati. Ciò riduce gravemente la latenza quando quei file devono essere letti come per la maggior parte, l'intero contenuto di un singolo file si trova per lo più su una singola traccia continua, quindi la testa delle unità avrebbe meno da fare quando trova ogni blocco contenente i dati che compone quell'unico file.

It (ext4) può ancora essere frammentato, ma molto meno e non necessariamente in un modo che influisce gravemente sulle prestazioni di lettura / scrittura come con NTFS. Su NTFS, i dati vengono scritti nei primi blocchi aperti nel percorso della testa.

Quindi, ovunque si trovi la testa e ci siano blocchi aperti, scrive tutti i dati che possono adattarsi, quindi scrive ovunque atterra altrove sul disco quando la testa deve spostarsi, diciamo, su un'altra parte del disco per accedere a un altro file che deve essere aperto in un programma appena caricato mentre l'altro file era ancora in fase di scrittura.
Ciò significa che se il file è di grandi dimensioni è probabile che sia distribuito in blocchi separati l'uno dall'altro su tracce separate ed è per questo che la deframmentazione è spesso necessaria per NTFS.

Inoltre, il motivo per cui i server generalmente non lo utilizzano in quanto vi sono operazioni di I / O più pesanti su un server in cui i dati vengono costantemente scritti e letti dal disco 24/7.

Inoltre non sono sicuro, ma se chkdskcontrolla l'integrità di ogni file (che credo sia e lo fsckfaccia), sarebbe anche più lento rispetto a ciò che ho appena descritto sulla frammentazione su NTFS.

Windows non dovrebbe mai aver bisogno di controllare un volume NTFS all'avvio. In tal caso, qualcosa è andato molto male, qualcosa di molto peggio di un semplice BSOD o di un'interruzione di corrente. Esiste una significativa possibilità che alcuni dei tuoi dati siano stati danneggiati anche da qualsiasi cosa abbia danneggiato i metadati del filesystem. Il controllo del disco non può rilevarlo; il suo unico scopo è evitare un'ulteriore corruzione.

KB2854570 elenca alcuni motivi per cui ciò può accadere. Uno è il letargo di un sistema operativo con un volume montato, modificando il contenuto del volume, quindi riprendendo dal letargo con il volume (ri) allegato. Se lo fai, c'è un'alta probabilità di corruzione silenziosa dei dati.

Non so perché il tuo filesystem ext4 si stesse controllando una volta alla settimana, ma probabilmente (probabilmente si spera) non era dovuto a una crisi comparabile che si ripeteva settimanalmente. Probabilmente stava solo eseguendo un controllo di integrità di routine e non un controllo di coerenza completo.