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.
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.
(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)
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.
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.
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 ?
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
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.
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.
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.
/tmp and /var/tmp)
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.
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.
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 !
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.
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.
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.
/var/spool/news and /var/spool/mail)
Elevée, surtout pour les gros serveurs de news. Pour les queues d'impression: lente. Pour les news on peut envisager du RAID0.
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)
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.
D'habitude un grand nombre de fichiers de quelques Ko, mais les fichiers d'une queue d'impression peuvent être assez gros.
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.
/home)
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.
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.
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 ?
A vous de voir. Le minimum des fichiers de démarrage de chaque utilisateur est une douzaine de fichiers pour environ 5 Ko.
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).
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.
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
/usr/bin et /usr/local/bin)
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.
200 Mo devraient suffire. Un serveur à usages multiples devrait peut-être réserver 500 Mo pour anticiper la croissance.
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.
La plupart entre 10 et 100 Ko. Certains assez gros (emacs ...)
/usr/lib and /usr/local/lib)
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.
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.
Basse. Comme pour les exécutables.
Assez gros avec un odre de grandeur de 1 Mo.
Pour des raisons historiques certains programmes (comme
GCC dans /usr/lib/gcc/lib) stockent des exécutables dans les
répertoires de librairies.
/)
Assez lent: il n'y a là que le minimum, et la plupart des programmes ne sont lancés qu'au démarrage.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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:
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.
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.
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.
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.
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é ?
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.
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.
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.
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.
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.
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.
md pour le noyau LinuxIl 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.
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.
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 !
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.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.
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.
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.
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.
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.
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.
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):
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.
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.