Lors de l'installation, vous pouvez choisir différents systèmes de fichiers pour vos partitions, c'est-à-dire, formater vos partitions selon différents algorithmes.
À moins d'être un spécialiste, le choix n'est pas forcément évident. Nous vous proposons ici une présentation rapide des trois systèmes de fichiers les plus courants, tous disponibles dans Mandrakelinux.
Le Second Extended File System (en abrégé ext2FS ou ext2) est le système de fichier par défaut de GNU/Linux depuis de nombreuses années. Il est le successeur de Extended File System (d'où le « Second »), dont il corrige certains problèmes et limitations.
Ext2 respecte les standards usuels des systèmes de fichiers pour systèmes de type Unix. Dès sa conception, il était destiné à évoluer, tout en offrant une grande robustesse et de bonnes performances.
Comme le nom le laisse supposer, le Third Extended File System (troisième système de fichiers étendu) est appelé à devenir le successeur de Ext2. Il conserve une compatibilité avec celui-ci, mais ajoute une fonctionnalité très intéressante : la journalisation.
Un des problèmes majeurs avec les systèmes de fichiers « traditionnels » comme Ext2, est leur faible tolérance aux pannes, telles qu'un arrêt brutal du système (coupure de courant ou plantage logiciel). En général, de tels événements se soldent par un examen très long de la structure du système de fichiers, des tentatives de corrections d'erreurs, parfois pour aboutir à une corruption étendue du système de fichiers. Donc, une perte partielle ou totale des données enregistrées.
La journalisation est une réponse à ce problème. Pour simplifier, disons que le principe consiste à enregistrer les actions à effectuer dans un journal avant de les effectuer réellement, un peu comme un capitaine de bateau note dans son journal de bord les événements de la journée. Le résultat est un système de fichiers qui reste toujours cohérent. En cas de problème, l'examen du système de fichiers consiste à regarder le journal et effectuer les actions qui n'ont pas eu le temps d'être effectuées avant le crash. Le temps de vérification d'un système de fichiers n'est donc plus proportionnel à la taille de celui-ci, mais à son degré d'utilisation.
Ext3 propose donc cette technologie, tout en conservant une structure interne basée sur Ext2FS, ce qui assure une excellente compatibilité. Cela rend même possible le basculement de ext2 vers Ext3 et inversement.
Au contraire de ext3, reiserfs est un système de fichiers recréé en partant de zéro. Il est également journalisé comme ext3, mais sa structure interne est radicalement différente notamment car il utilise le concept d'arbre binaire inspiré des bases de données, et a aussi une taille de bloc variable, ce qui le rend particulièrement performant pour des utilisations impliquant de très nombreux fichiers de petite taille. Il est aussi performant pour des fichiers de grande taille, en faisant donc un système très polyvalent.
JFS est le système de fichiers journalisé développé et utilisé par IBM. Initialement propriétaire et fermé, IBM a récemment décidé d'ouvrir l'accès au monde du Logiciel Libre à ce système de fichiers. Sa structure interne est proche de celle de ReiserFS.
XFS est le système de fichiers journalisé crée par SGI et utilisé par son système d'exploitation IRIX. Propriétaire et fermé au commencement, SGI a décidé de l'ouvrir au monde du Logiciel Libre. Sa structure interne a de nombreuses fonctionnalités comme un contrôle temps-réel de la bande passante, l'optimisation de l'espace disque, et les systèmes de fichiers distribués (clustered file systems (pas dans la version libre).
Tableau 9.1. Caractéristiques des systèmes de fichiers
Ext2 | Ext3 | ReiserFS | JFS | XFS | |
---|---|---|---|---|---|
Stabilité | Excellente | Très bonne | Bonne | Moyenne | Bonne |
Outils pour récupérer un fichier effacé | Oui (complexe) | Oui (complexe) | Non | Non | Non |
Temps de redémarrage après un crash | Long, voire très long | Rapide | Très rapide | Très rapide | Très rapide |
Intégrité des données en cas de crash | En général, bonne, mais il existe des risques de pertes partielles ou totales non négligeables | Très bonne | Moyenne[a] | Très bonne | Très bonne |
Support ACL | Oui | Oui | Non | Non | Oui |
[a] Il est possible
d'améliorer les résultats de la récupération d'un
crash en enregistrant dans le journal les
données en plus des
méta-données, en ajoutant
l'option |
À propos des tailles maximales de fichiers, cela dépend d'un grand nombre de paramètres (comme la taille des blocs pour ext2/ext3), et est susceptible d'évoluer suivant la version du noyau et l'architecture du système. Ceci étant, en ce qui concerne les limites du système de fichiers, le minimum disponible est actuellement généralement proche ou supérieur à 2To (1To=1024 Go) pour ext2 ou ext3 sur une machine 32 bits ; et peut atteindre 4 Po (1 Po=1024 To) pour JFS. Malheureusement, ces valeurs sont aussi limitées par la taille des périphériques bloc[24].
Avec le noyau 2.6.X, cette limite
sur la taille des blocs peut être étendue en utilisant un noyau
compilé avec le support Large Block
(CONFIG_LBD=y
). Pour plus d'information,
consulter Adding
Support for Arbitrary File Sizes to the Single UNIX
Specification, Large File Support in
Linux, and Large
Block Devices. Avec ceci, et un système de fichier le
permettant, on peut atteindre 16 TB (sur des machines 32-bit)
sans astuce liée au système de fichier comme le fait JFS pour la
taille du système de fichiers. Les fichiers stockés ici sont
limités à une plus petite taille.
Il est toujours très délicat d'effectuer un comparatif de performances. Tous les tests que l'on peut effectuer présentent diverses limitations, et les résultats doivent toujours être interprétés avec précaution. De plus, si ext2 est aujourd'hui très mature et évolue fort peu, les systèmes journalisés ext3 et reiserfs évoluent très rapidement. De nouvelles fonctionnalités pour reiserfs sont incluses dans reiserfs4[25]. D'un autre coté XFS a beaucoup de fonctionnalités avancées qui, avec le temps, marchent de mieux en mieux sous Linux. L'approche de JFS est totalement différente, mettant en oeuvre fonctionnalité après fonctionnalité, le processus étant plus long mais leur permettant d'avoir une base de code très propre. Des tests effectués il y a quelques mois ou quelques semaines sont déjà trop anciens. Par ailleurs, les performances physiques des matériels actuels (notamment des disques durs) estompent les différences. XFS a l'avantage d'être actuellement le plus performant sur de larges fichiers de flux.
Chaque système présente ses avantages et ses inconvénients, et en fait tout dépend de l'utilisation que vous comptez faire de votre ordinateur. Une simple machine de bureau pourra se contenter de ext2. Pour un serveur, on préférera sans doute un système de fichier journalisé comme ext3. reiserfs, peut-être du fait de ses origines, est plutôt recommandé pour un serveur de base de données. JFS sera préféré dans les cas où l'exigence principale est la rapidité du système de fichiers. XFS est intéressant si vous recherchez une de ses fonctionnalités avancées.
Pour une utilisation
« normale », les quatre systèmes de fichiers
présentent à peu près les mêmes performances
moyennes. reiserfs est plus rapide pour l'accès aux
fichiers de petites tailles, mais sensiblement plus lent pour
la manipulation de gros fichiers (plusieurs mégaoctets). Dans
la plupart des cas, les avantages de la journalisation de
reiserfs l'emportent sur ces inconvénients. Notez que
par défaut reiserfs est monté avec l'option
notail
. Cela signifie qu'il n'y a pas
d'optimisation pour les petits fichiers.
[24] Vous pouvez vous demander comment atteindre de telles capacités avec des disques durs qui atteignent difficilement les 320 – 400 Go. En fait, en utilisant une seule carte RAID hébergeant 8 disques de 250 Go en entrelacement RAID (RAID-striping), on atteint déjà 2 To de stockage. En combinant le potentiel de stockage de plusieurs cartes RAID en utilisant le logiciel RAID pour Linux, ou en utilisant la gestion de volumes logiques LVM (Logical Volume Manager), il devrait être possible de dépasser la limite des 4 To (si la taille des blocs le permet).
[25] Au moment de la rédaction de ce document, ReiserFS4 n'est pas encore inclus dans le noyau 2.6.X