La grosse nouveauté Ext4 de ce noyau est la possibilité de générer un code cyclique redondant de type CRC-32 sur les métadonnées du système de fichiers. Les codes cycliques redondants permettent, en échange d'une consommation plus importante de l'espace disque, à la fois de détecter et de réparer les données corrompues.
Dans la pratique, lorsqu'une corruption est détectée il est possible de ne monter le système de fichiers qu'en lecture seule afin d'éviter des pertes de données sur les systèmes corrompus. Cette fonctionnalité s'active via tune2fs si vous ne voulez par reformater votre partition. Par contre, un noyau antérieur à cette version ne pourra, dans tous les cas, que monter le système de fichiers en lecture seule. De plus fsck est capable d'utiliser cette information pour réparer le système de fichiers.
Rah je n'ai pas eu beaucoup de temps pour aider sur cette dépêche…
Ext4 a deux autres grosses nouveautés :
Inline data
Les tailles d'inodes sont prédéfinies (256o) et lorsqu'on n'utilise pas d'attributs étendus, de la place est perdue (ext4 utilise la moitié de la place). Pour les tout petits fichiers, il est maintenant possible de les stocker dans l'inode. Tao Ma's, l'auteur de cette fonctionnalité explique que sur ces tests il a réduit de 1% l'espace occupé pour l'ensemble du système et de 3% si on ne s'intéresse qu'à /usr.
Il faut noter qu'avec ce patch, un fichier tout petit qui serait amené à grossir, devrait être déplacé de l'inode vers l'espace de stockage classique. Il faut donc bien tester la pertinence de la solution avant de l'utiliser en production (sur des clusters par exemple).
Bigalloc
Ce patch s'attaque au problème de performance que peut poser les très grandes tables d'allocation avec des blocs de 4Kio sur des grands espaces de stockage.
Jusqu'à présent il était possible de définir des tailles de blocs plus gros pour gérer des système de fichiers qui gèrent quasiment que de gros fichiers. Cette solution manquait de souplesse, mais avais aussi d'autres inconvénients car elle impacte l'ensemble du systèmes comme les pages de cache.
Le bigalloc consiste a ajouter la notion de grappe d'inode. Ainsi le système de fichier peut utiliser de grands blocs sans impacter le reste du système. Lorsqu'une allocation d'un seul bloc est demandé alors le système de fichier maintiendra une correspondance entre les blocs noyau et ceux du système de fichier.
Cette solution permet un gain en espace disque car les tables d'allocation sont plus petites, mais aussi un gain lors des entrées sorties.
Voila
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Ext4
Posté par barmic . En réponse à la dépêche Sortie du noyau Linux 3.5. Évalué à 10.
Rah je n'ai pas eu beaucoup de temps pour aider sur cette dépêche…
Ext4 a deux autres grosses nouveautés :
Inline data
Les tailles d'inodes sont prédéfinies (256o) et lorsqu'on n'utilise pas d'attributs étendus, de la place est perdue (ext4 utilise la moitié de la place). Pour les tout petits fichiers, il est maintenant possible de les stocker dans l'inode. Tao Ma's, l'auteur de cette fonctionnalité explique que sur ces tests il a réduit de 1% l'espace occupé pour l'ensemble du système et de 3% si on ne s'intéresse qu'à
/usr.Il faut noter qu'avec ce patch, un fichier tout petit qui serait amené à grossir, devrait être déplacé de l'inode vers l'espace de stockage classique. Il faut donc bien tester la pertinence de la solution avant de l'utiliser en production (sur des clusters par exemple).
Bigalloc
Ce patch s'attaque au problème de performance que peut poser les très grandes tables d'allocation avec des blocs de 4Kio sur des grands espaces de stockage.
Jusqu'à présent il était possible de définir des tailles de blocs plus gros pour gérer des système de fichiers qui gèrent quasiment que de gros fichiers. Cette solution manquait de souplesse, mais avais aussi d'autres inconvénients car elle impacte l'ensemble du systèmes comme les pages de cache.
Le bigalloc consiste a ajouter la notion de grappe d'inode. Ainsi le système de fichier peut utiliser de grands blocs sans impacter le reste du système. Lorsqu'une allocation d'un seul bloc est demandé alors le système de fichier maintiendra une correspondance entre les blocs noyau et ceux du système de fichier.
Cette solution permet un gain en espace disque car les tables d'allocation sont plus petites, mais aussi un gain lors des entrées sorties.
Voila
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)