Pourquoi une vérification de disque Ext4 est-elle tellement plus rapide que NTFS?

J'ai eu une situation aujourd'hui où j'ai redémarré mon ordinateur et il m'a dit que je devais vérifier la cohérence du disque. Environ 10 minutes plus tard (à "1%" terminé), j'ai abandonné et j'ai décidé de le laisser fonctionner quand je rentre chez moi.

À titre de comparaison, mon ordinateur personnel utilise Ext4 pour toutes les partitions, et les vérifications de disque (qui s'exécutent une fois par semaine) ne prennent que quelques secondes. Je me souviens avoir lu que la vérification rapide du disque était une priorité, mais je ne sais pas comment ils pourraient le faire.

Alors, comment Ext4 effectue-t-il les vérifications de disque si rapidement? Y a-t-il une énorme percée dans ce domaine après la sortie de NTFS (il y a environ 10 ans)?

Remarque: le disque NTFS fait ~ 300 Go et le disque Ext4 fait ~ 500 Go. Les deux sont à moitié pleins.

Il existe deux raisons principales à la différence de performances et deux raisons possibles . Premièrement, les principales raisons:

Amélioration des performances d'ext4 par rapport à NTFS

Divers benchmarks ont conclu que le système de fichiers ext4 réel peut effectuer une variété d'opérations de lecture-écriture plus rapidement qu'une partition NTFS. Notez que bien que ces tests ne soient pas indicatifs des performances réelles, nous pouvons extrapoler ces résultats et les utiliser comme une raison.

Quant à savoir pourquoi ext4 fonctionne réellement mieux, NTFS peut être attribué à une grande variété de raisons. Par exemple, ext4 prend directement en charge l'allocation différée. Encore une fois cependant, les gains de performances dépendent strictement du matériel que vous utilisez (et peuvent être totalement annulés dans certains cas).

Exigences de vérification du système de fichiers réduites

Le système de fichiers ext4 est également capable d'effectuer des vérifications de système de fichiers plus rapides que d'autres systèmes de fichiers de journalisation équivalents (par exemple NTFS). Selon la page Wikipedia:

Dans ext4, les groupes de blocs non alloués et les sections de la table d'inode sont marqués comme tels. Cela permet à e2fsck de les ignorer entièrement lors d'une vérification et réduit considérablement le temps nécessaire pour vérifier qu'un système de fichiers de la taille ext4 est conçu pour être pris en charge. Cette fonctionnalité est implémentée dans la version 2.6.24 du noyau Linux.

Et maintenant, les deux raisons possibles :

Utilitaires de vérification du système de fichiers eux-mêmes

Certaines applications peuvent exécuter des routines différentes sur les systèmes de fichiers pour effectuer réellement le "contrôle de santé". Cela peut facilement être constaté si vous utilisez l' utilitaire fsck sous Linux par rapport à l' utilitaire chkdsk sous Windows. Ces applications sont écrites sur différents systèmes d'exploitation pour différents systèmes de fichiers. La raison pour laquelle je soulève cela comme une raison possible est que les appels système de bas niveau dans chaque système d'exploitation sont différents, et donc vous ne pourrez peut-être pas comparer directement les utilitaires à l'aide de deux systèmes d'exploitation différents.

Fragmentation du disque

Celui-ci est facile à comprendre et nous aide également à comprendre les différences entre les systèmes de fichiers. Bien que toutes les données numériques contenues dans un fichier soient identiques, la façon dont elles sont stockées sur le disque dur est très différente d'un système de fichiers à un autre. La fragmentation des fichiers peut évidemment augmenter les vitesses d'accès, ce qui est attribuable à une plus grande différence de vitesse.

D'après ma compréhension, ext4 essaie d'écrire des données dans le plus grand espace continu d'inodes ouverts où aucune donnée ne réside actuellement. Cela réduit considérablement la latence lorsque ces fichiers doivent être lus car, dans la plupart des cas, tout le contenu d'un fichier individuel se situerait principalement sur une seule piste continue, de sorte que la tête du lecteur aurait moins à faire pour trouver chaque bloc contenant les données. qui constitue ce seul fichier.

Il (ext4) peut encore devenir fragmenté, mais beaucoup moins et pas nécessairement d'une manière qui affecte gravement les performances de lecture / écriture comme avec NTFS. Sur NTFS, les données sont écrites dans les premiers blocs ouverts sur le chemin de la tête.

Donc, où que se trouve la tête et où il y a des blocs ouverts, elle écrit autant de données que possible, puis écrit partout où elle atterrit ailleurs sur le disque lorsque la tête doit se déplacer, par exemple, vers une autre partie du disque pour accéder à un fichier différent qui doit être ouvert dans un programme que vous venez de charger alors que cet autre fichier était encore en cours d'écriture.
Cela signifie que si le fichier est volumineux, il est susceptible d'être réparti en blocs séparés les uns des autres sur des pistes distinctes et c'est pourquoi la défragmentation est souvent nécessaire pour NTFS.

Aussi pourquoi les serveurs ne l'utilisent généralement pas car il y a des E / S plus lourdes avec un serveur où les données sont constamment écrites et lues à partir du disque 24/7.

De plus, je ne suis pas sûr, mais si chkdskvérifie l'intégrité de chaque fichier (ce que je crois et le fsckfais), il serait également plus lent en comparaison en raison de ce que je viens de décrire à propos de la fragmentation sur NTFS.

Windows ne devrait jamais avoir besoin de vérifier un volume NTFS au démarrage. Si c'est le cas, quelque chose s'est mal passé - quelque chose de bien pire qu'un simple BSOD ou une panne de courant. Il y a de fortes chances que certaines de vos données soient également corrompues par ce qui a corrompu les métadonnées du système de fichiers. La vérification du disque ne peut pas détecter cela; son seul but est d'éviter une nouvelle corruption.

KB2854570 répertorie certaines raisons pour lesquelles cela peut se produire. L'une consiste à mettre en veille prolongée un système d'exploitation avec un volume monté, à modifier le contenu du volume, puis à reprendre l'hibernation avec le volume (re) attaché. Si vous faites cela, il y a une forte probabilité de corruption silencieuse des données.

Je ne sais pas pourquoi votre système de fichiers ext4 se vérifiait une fois par semaine, mais ce n'était probablement (espérons-le) pas dû à une crise comparable qui se reproduisait chaque semaine. Il s'agissait probablement d'un simple contrôle de santé mentale et non d'un contrôle de cohérence complet.