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.
Hosting by: Hurra Communications GmbH
Generated: 2007-01-26 18:01:42