Page suivante - Page précédente - Table des matières

4. Considérations diverses

Avec le PC familial, un utilisateur récemment converti à Linux cherchera surtout à obtenir les meilleures performances pour un matériel donné. Quelqu'un qui achète une machine pour un usage spécifique (comme un fournisseur d'accès à Internet) cherche au contraire à se procurer le matériel en fonction de ses besoins. Ce HOWTO couvre les deux situations.

De manière générale, le mieux est d'avoir autant de disques que possible, mais on ne peut pas en rajouter indéfiniment et le coût est aussi un facteur. A taille totale égale, plus il y a de partitions et de disques, plus la maintenance est compliquée.

4.1 Usage des systèmes de fichiers

Les différentes parties du FSSTND n'ont pas les mêmes exigences en terme de vitesse, de taille et de fiabilité. Casser la racine / est pénible mais peut être facilement réparé, casser /var/spool/mail c'est une autre histoire. Voici un bref résumé des principales parties d'un système de fichiers. Notez que c'est indicatif, qu'on peut très bien avoir des binaires dans /etc ou /lib et des librairies dans bin, etc.

Swap

(ndT: le swap est une partie du disque utilisée pour prolonger la mémoire vive de la machine. Il se comporte donc exactement comme de la mémoire vive supplémentaire, mais en 1000 fois plus lent)

Vitesse

Maximum! Si toutefois vous dépendez trop du swap, achetez plus de mémoire vive. Attention au fait que sur la plupart des cartes mères le cache ne marchera pas au-delà de 128 Mo.

Taille

Entre 1 fois et 2 fois celle de la mémoire vive. 4 Mo + 4 Mo (mémoire + swap) suffisent pour un système minimaliste et 16 Mo + 40 Mo permettent d'être à l'aise.

Attention à prendre en compte le type d'applications que vous utilisez. Pour faire du calcul formel ou du ray-traycing il se peut que 128 Mo de mémoire et autant de swap soient nécessaires.

Autre raison de ne pas lésiner sur la taille du swap: certains programmes ne libèrent pas complètement la mémoire qu'ils ont allouée, causant ce qu'on appelle des fuites de mémoire. La mémoire n'est pas libérée, même quand le programme s'arrête. Lorsque la mémoire vive et le swap sont pleins, il n'y a plus qu'à redémarrer. Heureusement ce genre de programmes est peu fréquent, mais avoir beaucoup de swap vous donne de la marge.

Certains programmes bloquent leurs pages en mémoire vive (on ne peut donc pas les swapper). Ce peut être pour des raisons de sécurité ou de performance (par exemple pour un système temps réel). Bien sûr de tels programmes, en occupant de la mémoire qui ne peut être swappée, font que le système commence à utiliser le swap plus tôt que prévu.

Le manuel de mkswap (man 8 mkswap) explique que chaque partition de swap ne doit pas excéder 128 Mo sur une machine 32-bit et 256Mo sur une machine 64-bit.

Fiabilité

Moyenne. En cas de problème vous le savez assez vite et vous pouvez perdre le travail en cours. Vous sauvegardez souvent, n'est-ce pas ?

Note 1

Linux permet de bâtir un swap à cheval sur plusieurs disques. Taper man 8 swapon pour les détails. Cepandant, un swap réparti sur plusieurs disques est souvent plus lent.

L'entrée dans le fichier /etc/fstab doit ressembler à:

/dev/sda1       swap            swap    pri=1           0       0
/dev/sdc1       swap            swap    pri=1           0       0
Le fichier fstab est très sensible au formatage utilisé, donc lisez attentivement la page de man et ne copie-pestez pas les lignes précédentes.

Note 2

Certains utilisent un disque de mémoire vive (RAM disk) comme mémoire swap. Mais comme l'usage du swap est d'augmenter la mémoire vive et qu'un RAM disk diminue la quantité de mémoire vive disponible (en particulier pour le cache disque), cette solution est à proscrire.

Note 2bis

Il y a une exception: sur un certain nombre de cartes-mères mal conçues, le cache externe ne peut pas cacher toute la mémoire vive qui peut être adressée. Ces cartes-mères peuvent supporter 128 Mo, mais seuls les premiers 64 Mo bénéficieront du cache. Dans ces conditions, les performances seront améliorées si on utilise les 64 Mo restants comme un RAMdisk pour le swap ou le stockage temporaire.

Stockage temporaire(/tmp and /var/tmp)

Vitesse

Très élevée. Sur un disque ou une partition séparée, cela réduira la fragmentation, mais de toute façon ext2fs fragmente très peu.

Taille

Difficile à dire. A la maison quelques Mo suffisent mais sur un serveur, certains utilisateurs y stockent leurs fichiers de manière à échapper aux quotas et au contrôle, et cette partition peut grandir démesurément. Disons donc: entre 8 et 32 Mo à la maison, 128 Mo pour un petit serveur et jusqu'à 500 Mo (la machine utilisé par l'auteur sert 1100 utilisateurs avec un répertoire /tmp de 300 Mo). Gardez un oeil sur ces répertoires, pour les fichiers cachés ou bien trop vieux. Attendez-vous un de ces jours à devoir retailler vos partitions à cause d'un /tmp trop petit.

Fiabilité

Faible. Souvent les programmes évitent de planter et produisent le bon message d'erreur quand ces répertoires sont pleins ou provoquent une erreur. Des erreurs de fichiers aléatoires sont bien sûrs plus sérieuses, mais c'est le cas pour toutes les partitions !

Fichiers

Princicipalement de petits fichiers à durée de vie assez courte. Les programmes bien écrits effacent leurs fichiers dans /tmp mais si une erreur survient à ce moment-là ils ne plantent pas, donc de "vieux" fichiers peuvent traîner dans /tmp. Avec la plupart des distributions, on a la possibilité d'effacer tout le contenu de /tmp au démarrage.

Note 1

Dans le FSSTND il y a une note sur la possibilité de mettre /tmp dans un disque de mémoire vive. Cependant, pour les mêmes raisons que pour le swap, ce n'est pas recommandé. Comme ça a déjà été dit, n'utilisez pas de flash RAM pour ces répertoires. Gardez en tête que les fichiers de /tmp sont effacés au redémarrage, avec certaines distributions.

Note 2

Dans les vieux systèmes on trouve un répertoire /usr/tmp mais on recommande de ne pas l'utiliser. Pour les vieux programmes, on en a fait un lien symbolique vers les autres aires de stockage temporaire.

Queues (/var/spool/news and /var/spool/mail)

Vitesse

Elevée, surtout pour les gros serveurs de news. Pour les queues d'impression: lente. Pour les news on peut envisager du RAID0.

Taille

Pour les seveurs de news et de mail: dépend des besoins. Pour un seul utilisateur quelques Mo suffisent, si on ne part pas en vacances en étant abonné à 10 mailing lists ... (La machine que j'utilise au travail a 100 Mo pour /var/spool tout entier)

Fiabilité

Mail: très haute, news: moyenne, queue d'impression: basse. Si votre mail est très important (mais n'est-ce pas le cas ?) songez à une solution RAID.

Fichiers

D'habitude un grand nombre de fichiers de quelques Ko, mais les fichiers d'une queue d'impression peuvent être assez gros.

Note

Certaines documentations des news suggèrent de mettre tous les fichiers .overview dans un disque différent de celui des news. Voir les FAQs pour plus d'informations. La taille de ces fichiers est entre 3 et 10 pourcents du total.

Répertoires utilisateurs (/home)

Vitesse

Moyenne. Certains programmes (comme les client des news) font de fréquentes mises à jour dans les répertoires des utilisateurs, ce qui peut avoir une importance s'il y a beaucoup d'utilisateurs. Pour les petits systèmes la vitesse n'est pas critique.

Taille

A vous de voir ! Avec certains fournisseurs on paie selon la place disque, donc c'est une question de gros sous. De grands systèmes comme nyx.net (service Internet gratuit avec le mail, les news et la Toile) marchent bien avec une taille suggérée de 100 Ko par utilisateur et 300 Ko au grand maximum. Les fournisseurs commerciaux offrent autour de 5 Mo par utilisateur.

Si vous écrivez des livres ou si vous programmez, les besoins augmentent vite.

Fiabilité

Variable. Perdre /home sur un système personnel est ennuyeux, mais recevoir 2000 coups de fils d'utilisateurs qui se plaignent que leur répertoire a disparu est plus qu'ennuyeux. Pour certains c'est vital. Vous faites des sauvegardes régulières, n'est-ce pas ?

Fichiers

A vous de voir. Le minimum des fichiers de démarrage de chaque utilisateur est une douzaine de fichiers pour environ 5 Ko.

Note 1

Vous pouvez envisager le RAID pour la vitesse ou la fiabilité. Si vous voulez une vitesse et une fiabilité extrême, vous devriez envisager une autre solution logicielle et matérielle (serveurs haut-de-gamme, système avec tolérance aux pannes, etc).

Note 2

Les brouteurs Web utilisent souvent un cache local qui peut prendre beaucoup de place et provoquer beaucoup d'activité disque. Il y a plusieurs moyens d'éviter cela, voir Répertoires Utilisateurs et WWW.

Note 3

La tendance naturelle des utilisateurs est d'utiliser au maximum l'espace disque qu'on leur alloue. Le système de Quotas Linux permet de limiter le nombre de blocs et d'inodes qu'un seul utilisateur peut allouer par système de fichiers. Voir le Linux Quota mini-HOWTO

Exécutables ( /usr/bin et /usr/local/bin)

Vitesse

Lente. La vitesse de chargement d'un binaire n'est pas critique, j'en veux pour témoin les bonnes performances des systèmes "live" sur un CDROM.

Taille

200 Mo devraient suffire. Un serveur à usages multiples devrait peut-être réserver 500 Mo pour anticiper la croissance.

Fiabilité

Basse. Les binaires essentiels sont en général dans /bin et /sbin. Si l'on perd tous les binaires, c'est pénible car il faut tout réinstaller, mais pas dramatique.

Fichiers

La plupart entre 10 et 100 Ko. Certains assez gros (emacs ...)

Librairies (/usr/lib and /usr/local/lib)

Vitesse

Moyenne. On trouve là plein de choses, des fontes comme des librairies dynamiques. Souvent les fichiers sont chargés en entier et donc une vitesse suffisante est nécessaire.

Taille

Variable. C'est là par exemple que les traitement de texte stockent leurs dizaines de mégas de fontes et d'exemples. Le peu de personnes qui m'ont contacté m'ont parlé de 70 Mo, mais une installation Debian 1.2 complète peut prendre plus de 250 Mo. Parmi les plus gros consommateurs de place disque: GCC, Emacs, TeX/LaTeX, X11 et perl.

Fiabilité

Basse. Comme pour les exécutables.

Fichiers

Assez gros avec un odre de grandeur de 1 Mo.

Note

Pour des raisons historiques certains programmes (comme GCC dans /usr/lib/gcc/lib) stockent des exécutables dans les répertoires de librairies.

Racine (/)

Vitesse

Assez lent: il n'y a là que le minimum, et la plupart des programmes ne sont lancés qu'au démarrage.

Taille

Assez petit. Cepandant c'est une bonne idée de garder quelques fichiers et utilités de dépannage et plusieurs versions du noyau. 20 Mo devraient suffire.

Fiabilité

Elevée. Une panne de la racine peut être relativement coûteuse en temps et en cheveux arrachés. Avec de la pratique vous pourrez faire cela en un heure, mais si vous avez l'habitude de ce genre de choses c'est que quelque chose ne va pas.

Naturellement, vous avez une disquette de secours ? Et vous l'avez mise à jour régulièrement ? Il y a des disquettes toutes faites et des utilitaires de création de disquette de secours. Y passer un peu de temps peut vous épargner de devenit un expert en réparation de la partition racine.

Note 1

Si vous avez plein de disques, pourquoi ne pas mettre une partition de boot de secours sur un disque physiquement différent de celui sur lequel vous démarrez habituellement ? Le peu d'espace que ça vous coûtera sera amplement compensé par le temps gagné en cas de panne.

Note 2

Pour la simplicité comme pour le dépannage, il n'est pas recommandé de mettre la partition racine sur un système RAID niveau 0. Si vous utilisez RAID pour votre partition racine, il faut mettre l'option md pour votre noyau de secours.

Note 3

Pour démarrer avec Lilo il est important que les fichiers essentiels au démarrage résident entièrement dans les 1023 premiers cylindres. Ce qui comprend le noyau et les fichiers du répertoire /boot.

DOS, etc.<

Au risque de paraître hérétique j'ai inclus ce paragraphe au sujet duquel beaucoup ont des réaction vives. Malheureusement pas mal de disques sont livrés avec des outils d'installation et de maintenance basé sur ces systèmes et il faut en tenir compte.

Vitesse

Très lente. Les systèmes en question ne sont pas réputés pour leur vitesse donc il y a peu d'intérêt à utiliser des disques dernier cri. Le multitâche ou le multithread ne sont pas disponibles, donc les possibilités des disques SCSI ne sont pas pleinement exploitées. Un vieux disque IDE devrait faire l'affaire. Notons que Windows 95 et NT supportent le multi-tâches et devraient donc mieux profiter des caractéristiques du SCSI.

Taille

La compagnie qui produit ces systèmes n'est pas réputée pour écrire des programmes petits et optimisés, attendez-vous à y consacrer plusieurs dizaines de Mo. Avec une vieille version de DOS ou Windows ça peut tenir dans 50 Mo.

Fiabilité

Ha-ha. Comme une chaîne a la force de son maillon le plus faible, vous pouvez utiliser un vieux disque. Comme l'OS est plus facilement susceptible de s'auto-détruire que le disque, vous apprendrez sans doute ici l'importance des sauvegardes de secours.

Dit autrement: "Votre mission, allez-vous l'accepter, est de garder cette partition en état de servir. Cette mise en garde s'auto-détruira dans 10 secondes ..."

On m'a demandé récemment de justifier mes prises de positions dans ce paragraphe. D'abord je m'excuse mais je n'appelle pas DOS et Windows des systèmes d'exploitation. Ensuite il y a des implications légales à prendre en considération. Je ne donnerai au lecteur que quelques mots-clés: DOS 4.0, DOS 6.x et divers utilitaires de compression disque dont le nom devrait rester secret.

4.2 Explication des termes

Bien sûr le plus rapide est le mieux mais souvent le joyeux installateur de Linux a plusieurs disques de vitesse et de qualité variable. Bien sûr ce document pour rester utile à tous doit être général et ne saurait envisager tous les cas particuliers. Même ainsi il y a quelques détails à retenir:

Vitesse

C'est un mélange de plusieurs termes: charge du processeur principal, temps de mise en place du transfert, temps d'accès et taux de transfert. Il n'y a pas d'optimum fixé mais souvent le prix est le facteur déterminant. La charge processeur varie uniquement pour les disques IDE (car c'est le processeur principal qui pilote le disque), et pour les SCSI elle est toujours assez faible. Le temps d'accès est assez petit, quelques millisecondes. Il intervient assez peu si on utilise la queue des commandes SCSI, on peut alors lancer d'autres commandes pendant que les premières attendent leur réponse et le bus est occupé tout le temps au mieux. Dans le cas des serveurs de news, qui ont un grand nombre de petits fichiers, le temps d'accès peut être avoir plus d'influence sur la vitesse globale.

Les deux principaux paramètres sont:

Temps d'accès

Habituellement on donne le temps moyen pris par la tête de lecture pour aller d'une position à une autre au hasard. Ce paramètre a plus d'importance s'il y a beaucoup de petits fichiers. Il y a aussi un petit délai avant que le secteur désiré tourne et se retrouve en face de la tête. Ce délai est proportionnel à la vitesse angulaire. Des valeurs courantes de vitesse angulaire sont 4500, 5400 et 7200 tours/min. Les disques tournant plus vite sont donc plus rapides, mais ils coûtent plus chers, sont parfois bruyants et génèrent de la chaleur, paramètre qui compte si vous avez toute une rangée de disques. Avec les tous récents disques à 10000 tours/min les besoins de refroidissement sont encore plus grands et des schémas d'aération minimale sont donnés.

Taux de transfert

En Mo/s. Ce paramètre est plus important si on a peu de grands fichiers. A densité égale, la vitesse de transfert est proportionnelle à la vitesse angulaire.

Il est important de lire les spécifications des disques très attentivement, et de noter que le taux de transfert maximum est donné comme le taux de transfert entre la mémoire cache du disque et la mémoire principale, et pas comme le taux de transfert moyen entre le disque et la mémoire principale. Voir aussi Consommation et Chaleur.

Fiabilité

Bien sûr personne ne voudrait d'un disque pas très fiable. On ferait mieux de considérer les vieux disques comme non fiables. Pour le RAID il est suggéré d'utiliser un ensemble de disques différents de telle sorte que les pannes simultanées soient moins probables.

Autant que je sache, je n'ai connu qu'un cas d'un système de fichiers totalement foutu, mais dans ce cas un matériel instable semblait la cause des problèmes.

Les disques ne sont pas chers de nos jours et les gens sous-estiment toujours la valeur du contenu de leurs disques durs. Si vous avez besoin de matériel fiable, remplacez vos vieux disques et gardez des roues de secours. Un disque peut marcher plus ou moins en continu pendant des années, mais ce qui tue un disque c'est souvent en fin de compte les variations de tension.

Fichiers

La taille moyenne des fichiers est importante pour décider les bons paramètres du disque. Avec beaucoup de petits fichiers c'est le temps d'accès qui compte, et avec peu de gros fichiers c'est plutôt le taux de transfert. La queue des commandes SCSI est très bien adaptée à la gestion de beaucoup de petits fichiers, tandis que pour le taux de transfert EIDE et SCSI sont à peu près équivalents.

4.3 Technologies

Quelles sont les technologies disponibles et qu'est-ce que leur choix implique en terme de vitesse, fiabilité, consommation, flexibilité, facilité d'usage et complexité ?

RAID

C'est une méthode pour augmenter la fiabilité ou la vitesse ou les deux en utilisant plusieurs disques en parallèle. Ainsi les temps d'accès et taux de transferts sont diminués. Avec des miroirs et des vérifications (checksums) on peut améliorer la fiabilité. Ils sont un bon choix pour de gros serveurs mais pour un PC autant tuer une mouche au pistolet laser. Voir les documents et FAQs sur ce sujet.

Avec Linux on peut utiliser un système RAID soit logiciel (le module md du noyau) soit matériel avec un contrôleur supporté, qu'il soit PCI-SCSI ou SCSI-SCSI. Une solution matérielle est plus rapide, mais bien sûr plus chère.

Les contrôleurs SCSI-SCSI sont d'habitude réalisés comme un ensemble de disques et un contrôleur, communiquant entre eux par un second bus SCSI et qui se connectent au bus SCSI. De l'extérieur, l'ensemble se comporte comme un seul disque SCSI. Mais cette connexion au bus SCSI peut être un facteur limitant pour les performances. Un avantage significatif de ce genre de matériel est pour les gens qui ont de grands ensembles de disques durs: comme le nombre d'entrées SCSI dans le répertoire /dev est limité, cette solution permet d'utiliser plusieurs disques avec un seul fichier de périphérique.

Les contrôleurs PCI-SCSI, comme leur nom l'indique, sont connectés au bus PCI qui est plus rapide qu'un bus SCSI. Ces contrôleurs ont besoin de drivers spéciaux mais ils offrent du coup la possibilité de configurer le RAID à travers le réseau, ce qui simplifie l'administration.

Actuellement seules quelques familles de cartes PCI-SCSI sont supportées par Linux.

DPT

Les plus anciens et les plus matures sont les contrôleurs de DPT parmi lesquels le SmartCache I/III/IV et le SmartRAID I/III/IV. Ces contrôleurs sont supportés par le pilote EATA-DMA du noyau standard. Cette société a aussi une page d'information qui décrit certains aspects des technologies RAID et SCSI en plus de l'information sur leurs produits.

On peut consulter les page de l'auteur des pilotes pour contrôleurs DPT sur SCSI et sur DPT.

Ces contrôleurs ne sont pas les plus rapides mais leur fiabilité n'est plus à prouver.

ICP-Vortex

Très récemment des contrôleurs de ICP-Vortex offrant jusqu'à 5 canaux indépendants et un matériel très rapide basé sur la puce i960. Le pilote a été écrit par le fabricant lui-même, qui prouve ainsi qu'il soutient Linux.

DAC-960

Encore en bêta-version. Plus d'information dans un futur proche.

Les contrôleurs SCSI-SCSI sont de petits ordinateurs, souvent avec une quantité appréciable de mémoire vive. Ils se présentent du point de vue extérieur comme un disque énorme, rapide et fiable. Ils n'ont donc pas besoin de pilote particulier (en plus de celui de la carte SCSI principale). Certains de ces contrôleurs ont une option pour parler à plusieurs adresses simultanément. D'habitude ils sont configurés grâce à une interface ou à un émulateur de terminal vt100 connecté à leur interface série.

Récemment j'ai appris que Syred faisait aussi des contrôleurs SCSI-SCSI supportés par Linux. Je n'ai pas plus d'information mais on peut regarder sur leur site: www.syred.com

Je ne donne ici qu'un rapide aperçu du RAID qui a beaucoup de niveaux et de variantes. Le lecteur intéressé est invité à consulter la FAQ RAID.

  • Le mode RAID 0 n'est pas redondant du tout mais offre le plus de vitesse. Les données sont réparties sur plusieurs disques et les opérations de lecture/écriture se font en parallèle. D'un autre côté, si un disque a une panne tout est fichu. Ai-je déjà mentionné les sauvegardes ?
  • Le mode RAID 1. C'est la méthode la plus primitive pour obtenir de la redondance: les données sont copiées sur chaque disque. C'est bien sûr un immense gâchis mais on a un grand avantage: un temps moyen d'accès très court. En effet les ordre de lecture sont envoyés à tous les disques et c'est le premier à répondre qui gagne. Le taux de transfert n'est pas significativement plus élevé qu'avec un seul disque, mais en lisant une piste différente sur chaque disque on peut parfois gagner du temps. Si vous n'avez que 2 disques c'est la seule façon d'avoir de la redondance.
  • Les modes RAID 2 et 4 ne sont pas très courants et on n'en parlera pas ici.
  • Le mode RAID 3 utilise plusieurs disques (au moins 2) pour mettre des données réparties comme en RAID 0. Il utilise aussi des disques redondants pour stocker le OU exclusif des données des disques de données. Si le disque redondant tombe en panne, le système peut continuer à fonctionner sans problème. Si c'est un disque de données qui crashe, le système peut récupérer les données à partir des disques redondants et des autres. Une panne double met le système hors-service. Le mode RAID 3 ne fait du sens qu'avec au moins 2 disques de données et un pour la redondance. Il n'y a pas de limite théorique, mais la probabilité de panne augmente avec le nombre de disques. La limite habituelle est de 5 à 7 disques. Comme toutes les opérations d'écriture doivent être répercutées sur le disque redondant, la vitesse globale en écriture d'un ensemble RAID 3 est celle de son disque redondant. La vitesse en lecture est celle d'un système RAID 0 ayant autant de disques que le RAID 3 a de disques non redondants. La vitesse chute sévèrement lorsque l'ensemble doit restaurer les données depuis le disque redondant.
  • Le mode RAID 5 est comme le RAID 3, mis a part que l'information redondante est répartie sur l'ensemble des disques. Ça augmente la vitesse en écriture, puisque la charge est répartie.

Il y a aussi des modes hybrides basés sur le RAID 0 ou 1, et un autre niveau. Beaucoup de combinaisons sont possibles mais certaines sont assez complexes.

Le RAID 0/1 combine la répartition et la duplication, ce qui donne de très bons taux de transfert et temps d'accès moyen. Le revers de la médaille est que ça requiert beaucoup de disques et que c'est complexe.

Le RAID 1/5 combine la redondance façon RAID 5 et le court temps d'accès du RAID 1. La redondance est améliorée par rapport au RAID 0/1 mais la consommation de disques est significative. Il faudra au moins 6 disques pour mettre en place une telle solution, et peut-être plusieurs canaux ou contrôleurs SCSI.

AFS, Veritas et autres systèmes de gestion de volume

Avoir de nombreux disques et partitions constitue un avantage pour la taille, la vitesse et la fiabilité mais il y a un hic: Si la partition /tmp est pleine vous êtes bien embêté même s'il y a de la place dans la partition pour les news, car il n'est pas évident de retransférer les quotas d'une partition à l'autre. Les systèmes de gestion de volume font précisément ce travail. Les plus connus sont AFS et Veritas. Ils offrent aussi d'autres fonctions comme un journal des opérations disque. Veritas n'est pas disponible pour Linux, et il n'est pas certain qu'il puissent vendre des modules du noyau sans publier le code source, il est donc juste mentionné pour information. Pour voir comment ces systèmes fonctionnent vous pouvez consulter le site de veritas.

Derek Atkins, du MIT, a porté AFS pour Linux et mis en place la Linux AFS mailing List qui est ouverte au public. Pour s'abonner à cett mailing-list il faut envoyer un mail à linux-afs-request@mit.edu et si on trouve un bug linux-afs-bugs@mit.edu.

Attention: comme AFS utilise du cryptage il est restreint d'usage dans certains pays (ndT: la France par exemple). AFS est maintenant vendu par Transarc et ils ont mis en place un site Web. Voir le site de Transarc pour des informations générales et une FAQ.

Il y a aussi des développements basés sur la dernière version libre d'AFS.

La gestion de volume est pour l'instant un des gros manques de Linux. Un projet a démarré au sujet d'un système de partitions virtuelles qui réalisera la plupart des fonctions de gestion de volume qu'on trouve dans le système AIX d'IBM.

Le patch md pour le noyau Linux

Il y a un projet de la part des développeurs du noyau, md, qui fait partie de la distribution du noyau depuis la version 1.3.69. md offre diverses fonctions telles que le RAID mais il est envore en phase de développement. Les gens qui l'ont utilisé parlent d'un succès mitigé voire d'un crash total. Bref, soyez prudents.

Actuellement md permet le mode linéaire et le RAID niveau 0,1,4 et 5: le plus stable doit être le RAID niveau 0 et 1, le reste est encore en développement. Il est aussi possible d'empiler les niveaux, par exemple de constituer un RAID 1 avec deux paires de disques, chaque paire étant un montage RAID 0.

Il faut bien prévoir quels disques on combine de manière à faire tourner tous les disques en parallèle, ce qui augmente les performances. Pour plus de détails se reporter à la documentation de md.

Considérations générales sur les systèmes de fichiers.

Dans le monde Linux ext2fs s'est imposé comme le système de fichiers à tout faire. Mais pour certains usages spécifiques, d'autres systèmes de fichiers sont préférables. Pour les serveurs de news un système avec journal (log file systems) est un choix naturel. C'est l'objet de vives controverses et il n'y a que peu de choix actuellement, mais on avance dans ce domaine. Les systèmes de fichiers avec journal ont l'avantage d'une vérification rapide. Un serveur de mail dans la classe 100 Go pourrait souffrir d'une vérification de systèmes de fichiers (avec fsck) prenant plusieurs jours au redémarrage.

Le système de fichiers de Minix est le plus ancien, très peu utilisé actuellement. Le système Xiafs était un candidat sérieux pour devenir le standard de Linux mais il n'a pas vécu.

Adam Richter d'Yggdrasil a posté récemment un message au sujet d'un système de fichiers avec journal et compression, mais c'est encore en développement. Une version qui ne marche pas est disponible sur le serveur ftp d'Yggdrasil avec des versions patchées du noyau. Peut-être que ça sera prochainement inclus dans la distribution officielle du noyau.

Le 23 juillet 1997, Hans Reiser a publié les sources d'un système de fichiers basé sur la notion d'arbre, reiserfs. Ce système a des fonctionnalités très intéressantes et il est plus rapide que ext2fs, mais il est encore expérimental et pas facile à intégrer dans le noyau. on peut attendre d'importants développements dans le futur. Ce projet se distingue du système de fichiers avec journal moyen car Hans a déjà du code qui tourne.

Dans le système ext2fs existant, on pourrait ajouter de nouvelles fonctions comme les listes de contrôle d'accès (ACL, Access Control List), là encore dans un proche futur.

Il existe aussi un système de fichiers avec cryptage, mais un fois encore vérifiez qu'il est légal dans votre pays (ndT: rappel: en France c'est illégal pour le moment).

Les systèmes de fichiers sont un champ de recherches académiques et industrielles important, recherches dont les résultats sont souvent accessibles gratuitement (ndT: Il n'y a que les clients d'Apple ou Microsoft qui utilisent des technologies vieilles de 10 ans ...). Linux étant souvent la plate-forme de développement de tels prototypes, on peut s'attendre a des améliorations et des innovations continuelles.

Systèmes de fichiers des cédéroms

Il y a un certain nombre de systèmes de fichiers disponibles pour les cédéroms. Le plus ancien est le format High Sierra, nommé ainsi d'après l'hôtel où les accords furent signés par les partenaires industriels. C'était l'ancêtre de l'ISO 9660, qui est supporté par Linux (ndT: ce fut le nivellement par le bas: noms de fichiers de 8+3 caractères, majuscules/minuscules confondues, etc). Plus tard une extension Rock Ridge fut proposée, ajoutant les noms de fichiers longs et les droits d'accès entre autres.

Le système de fichiers iso9660 de Linux supporte aussi bien le vieux High Sierra que les extensions Rock Ridge.

Cepandant, une fois de plus Microsoft a décidé de choisir une de ces technologies comme nouveau "standard". Leur dernier bébé s'appelle Joliet et offre des possibilités d'internationaliation. Ce format est accepté par le noyau Linux depuis la version 2.0.34. Vous devez activer NLS pour l'utiliser.

H. Peter Anvin (hpa (at) transmeta.com) a récemment posté ces lignes:

Actually, Joliet is a city outside Chicago; best known for being the
site of the prison where Elwood was locked up in the movie "Blues
Brothers."  Rock Ridge (the UNIX extensions to ISO 9660) is named
after the (fictional) town in the movie "Blazing Saddles."

En fait, Joliet est une cité pas loin de Chicago, surtout célèbre pour
sa prison où Elwood était enfermé dans le film "Blues Brothers". Rock
Ridge (l'extension UNIX de l'ISO 9660) fut baptisé d'après la ville
imaginaire du film "Blazing Saddles."

En fait c'était Jake qui était enfermé. Oups !

Compression

Faut-il compresser son disque ou ses fichiers ? Voilà une question âprement débattue, surtout si on prend en compte le danger de perte de fichiers. Il y a pourtant plusieurs options pour les administrateurs aventureux: modules ou patchs du noyau, librairies. La plupart de ces solutions ont de limitations, comme par exemple d'être en lecture seule. Seules quelques références sont données ici; à vous de vous tenir au courant des dernières mises à jour.

  • DouBle offre la compression de fichiers avec certaines limitations.
  • Zlibc ajoute la compression au vol des fichiers quand on les charge, de façon transparente.
  • Il y a beaucoup de modules qui permettent de lire des fichiers compressés ou des partitions natives de plusieurs systèmes d'exploitation, mais la plupart sont en lecture seule.
  • dmsdos (actuellement en version 0.9.1.2) offre la plupart des options de compression de DOS et Windows. Il n'a pas encore tout mais de nouvelle fontionnalités sont régulièrement ajoutées.
  • e2compr étend ext2fs avec des fonctions de compression. Il est pour le moment en phase de test donc utilisable seulement pour des hackers du noyau. Voir la page de e2compr pour plus d'information. J'ai eu des rapports selon lesquels c'est assez stable et rapide.

Autres systèmes de fichiers

Il y a le système de fichiers userfs qui permet un système de fichiers basé sur FTP, et a entre autres des possibilité de compression. docfs est basé sur ce système de fichiers.

Avec les ajouts récents au noyau, on peut mettre un système de fichiers complet dans un seul fichier (appelé loopback device). On peut utiliser ça pour concevoir et tester de nouveaux systèmes de fichiers.

Notez que cela n'a rien a voir avec le network loopback device.

Il y a aussi un certain nombre de systèmes de fichiers au stade expérimental qui ne sont pas évoqués ici.

Position physique des pistes

Avec les disques petits et lents, certain systèmes de fichiers utilisaient au mieux les caractéristiques physiques lors du placement des données stockées. Cependant, l'augmentation de la vitesse et l'apparition de contrôleurs intégrés avec mémoire cache ont réduit l'effet de ces optimisations.

Néanmoins, on peut toujours gagner un peu avec ce genre d'optimisations. Comme chacun le sait, Linux va un jour dominer le monde, mais pour que ce jour arrive plus vite il nous faut employer toutes les ressources.

La plupart des disques tournent à vitesse angulaire constante mais utilisent une densité des données à peu près constante sur toutes les pistes. On a donc un taux de transfert bien plus élevé sur le bord que sur l'intérieur du disque. Mais il y a aussi le fait que le temps d'accès moyen aux données sockées sur le centre du disque est plus court que pour les données stockées au centre ou à l'extérieur.

Mais les disques récents utilisent une géométrie "logique" différente de la géométrie physique, le disque lui-même effectuant la conversion. Trouver le "milieu" du disque est plus difficile dans ces conditions.

Dans la plupart des cas la piste 0 est la plus à l'extérieur mais c'est une convention et pas une norme.

Les pistes intérieures

sont plus lentes pour le taux de transfert comme pour le temps d'accès.

Elles sont plus adaptées à des partitions telles que DOS, la racine ou la queue d'impression, qui ne demandent pas de vitesse élévée.

Les pistes du milieu

sont en moyenne plus rapides que les pistes intérieures pour le taux de transfert comme pour le temps d'accès. Elles sont bien adaptées pour des partitions comme swap, /tmp et /var/tmp.

Les pistes extérieures

ont le taux de transfert le plus rapide mais un temps d'accès moyen aussi faible que les pistes intérieures. C'est là qu'on pourra mettre de gros fichiers comme des librairies.

Le temps d'accès moyen peut être réduit en plaçant au centre les pistes les plus fréquemment demandées. Cela peut être fait avec fdisk en découpant un partition dans les pistes du milieu. Ou bien, avec un disque vide au départ, on peut copier un fichier bidon avec dd de la taille de la moitié du disque environ; on crée ensuite les fichiers qui ont besoin d'un accès rapide et on efface le fichier bidon.

Le dernier cas sert surtout pour les queues d'impression: on met le répertoire vide de départ au milieu du disque, ce qui réduira aussi la fragmentation.

Avec les systèmes RAID on peut aussi placer des fichiers au centre, mais le calcul est plus compliqué: voir la documentation sur RAID. On peut gagner jusqu'à 50 pourcents.

Vitesse des disques

Le système mécanique est souvent le même dans des disques IDE ou SCSI. Les contraintes mécaniques sont aujourd'hui un facteur limitant même si les progrès continuent. Il y a deux paramètres principaux, habituellement notés en millisecondes (ms):

Mobilité de la tête

La vitesse à laquelle la tête de lecture-écriture peut aller d'une piste à une autre, aussi appelé temps d'accès. Si vous calculez la double intégrale (la moyenne) de la distance sur tous les points de départ et tous les points d'arrivée possibles, vous trouverez que c'est équivalent à 1/3 de l'ensemble des pistes.

Vitesse de rotation

Elle détermine le temps nécessaire pour se placer dans le bon secteur, temps appelé latence.

Quelques valeurs typiques de temps mouvement de la tête:

 Type de disque
Temps d'accès (ms)      | Rapide Moyen Vieux
---------------------------------------------
Pistes voisines             <1     2     8
En moyenne                  10    15    30
Au pire                     10    30    70

On voit que les disques dernier cri ont des temps d'accès à peine meilleurs que les disques moyens, mais que les vieux disques sont significativement moins bons.

Vitesse de rotation (tr/min)  |  3600 | 4500 | 4800 | 5400 | 7200 | 10000
---------------------------------------------------------------------------
Latence (ms)                  |    17 |   13 | 12.5 | 11.1 |  8.3 |   6.0

Comme la latence est le temps moyen pour atteindre un autre secteur, la formule est assez simple:

latence (ms) = 60000 / vitesse (tr/min)

Ce tableau montre lui aussi que la vitesse des disques progresse moins qu'auparavant. En revanche, la consommation d'électricité, l'échauffement et le bruit augmentent beaucoup.


Page suivante - Page précédente - Table des matières