3. De quelles partitions ai-je besoin ?

3.1 De combien de partitions ai-je besoin ?

Donc, de quelles partitions ai-je besoin ? Pour commencer, certains syst�mes d'exploitation ne croient pas au d�marrage � partir de partitions logiques pour des raisons qui sont � la port�e de tout esprit sain. De ce fait, vous voudrez certainement r�server vos partitions primaires comme partitions d'amor�age pour MS-DOS, OS/2 et Linux ou pour quelque autre syst�me que vous utilisiez. Rappelez-vous toutefois qu'une partition primaire est n�cessaire pour cr�er la partition �tendue qui servira de container pour les partitions logiques qui occuperont le reste de votre disque.

L'amor�age des syst�mes d'exploitation se passe en mode r�el et implique toutes les limitations li�es au BIOS, et surtout celle des 1024 cylindres. Vous voudrez donc probablement placer toutes vos partitions de d�marrage dans les 1024 premiers cylindres de votre disque dur, afin d'�viter des complications. A nouveau, je vous invite � lire le "large-disk Mini-HOWTO" pour les d�tails saignants.

Pour installer Linux, vous aurez besoin d'au moins une partition. Si le noyau est charg� depuis cette partition (par exemple gr�ce � LILO), cette partition doit �tre lisible du BIOS. Si vous chargez votre noyau par d'autres moyens (par exemple depuis une disquette d'amor�age ou avec LOADLIN.EXE, le lanceur de Linux depuis MS-DOS), cette partition peut �tre n'importe o�. Dans tous les cas, le type de cette partition sera "Linux native", code 0x83.

Votre syst�me aura besoin d'espace swap. A moins de swaper sur des fichiers, il vous faudra une partition swap d�di�e. Du fait que ce type de partition n'est accessible que par le noyau de Linux, et que ce noyau n'est pas affect� par les d�ficiences du BIOS de votre PC, la partition swap peut �tre install�e n'importe o�. Je recommande d'utiliser pour cela une partition logique (/dev/?d?5 ou une des suivantes). Les partitions swap d�di�es de Linux sont de type "Linux swap", code 0x82.

Ces exigences sont le minimum en terme de partitions. Il peut toutefois se r�v�ler utile de cr�er plus de partitions pour Linux, comme la suite le montrera.

3.2 Quelle taille attribuer � ma zone swap ?

Si vous avez d�cid� d'utiliser une partition d�di�e � la zone swap, ce qui est une Bonne Id�e [tm], consid�rez les indications suivantes pour estimer sa taille :

• Sous Linux, la taille de la RAM et celle de la zone swap s'additionnent (ce qui n'est pas vrai pour tous les Unix). Par exemple, si vous avez 8 Mo de RAM et 12 Mo de swap, vous disposez d'un total d'environ 20 Mo de m�moire virtuelle.
• En choisissant la taille de votre zone swap, gardez pr�sent � l'esprit que vous devriez disposer d'au moins 16 Mo de m�moire virtuelle. Ainsi pour 4 Mo de RAM envisagez un minimum de 12 Mo de swap ; pour 8 Mo de RAM, envisagez un minimum de 8 Mo de swap.
• Sous Linux, une partition swap ne peut pas exc�der 128 Mo. En r�alit�, sa taille pourrait d�passer 128 Mo, mais l'espace en exc�s ne serait jamais utilis�. Si vous voulez plus de 128 Mo de swap, vous devez cr�er plusieurs partitions swap.
• En choisissant la taille de votre zone swap, rappelez vous qu'une zone swap trop grande ne sera pas vraiment utile. Tout processus poss�de un "jeu d'instructions" qui correspond � un ensemble de pages m�moire, et auquel le processeur acc�dera � nouveau dans un temps tr�s court. Linux essaie de pr�voir ces acc�s m�moire (en partant du principe que les pages r�cemment utilis�es le seront � nouveau dans un futur proche) et conserve ces pages dans la RAM si c'est possible. Si le programme respecte strictement le principe de localit�, cette hypoth�se sera v�rifi�e, et l'algorithme de pr�diction fonctionnera. Conserver en m�moire une zone de travail n'a de signification que s'il y a suffisamment de m�moire. Si trop de processus s'ex�cutent en m�me temps sur une m�me machine, le noyau est alors dans l'obligation de paginer des donn�es auxquelles il devra acc�der de nouveau tr�s rapidement (il faudra donc paginer sur disque des donn�es provenant d'une autre zone de travail pour pouvoir les appeler en m�moire). Ceci induit g�n�ralement une augmentation critique de l'activit� de pagination, et donc une substantielle baisse de performances. On dit d'une machine dans cette situation qu'elle "rame". Sur une machine qui rame, les processus tournent essentiellement sur disque, et non dans la RAM. On peut donc s'attendre � une chute de performances de l'ordre de grandeur du rapport entre le temps d'acc�s m�moire et le temps d'acc�s disque. Mon petit doigt m'a parl� d'une tr�s vieille r�gle datant de l'�poque du PDP et du Vax, et qui est la suivante : la taille du jeu d'instructions d'un programme est �gale � environ 25 % de sa taille virtuelle. Ainsi, il est sans doute inutile de pr�voir plus de swap que trois fois la taille de votre RAM. Mais rappelez-vous que c'est seulement mon petit doigt qui me l'a dit. On peut facilement imaginer des cas ou les programmes ont un tr�s grand, ou au contraire un tr�s petit jeu d'instructions. Par exemple, un programme de simulation avec un tr�s grand jeu de donn�es auxquelles il acc�de de mani�re quasi al�atoire ne respectera pas vraiment le principe de localit� dans son segment de donn�es, et donc son jeu d'instructions sera relativement important. D'un autre c�t�, xv avec de nombreux JPEGs ouverts simultan�ment, mais tous iconifi�s sauf un, aura un tr�s gros segment de donn�es. Mais les op�rations ne sont faites que sur une seule image � la fois, et donc la plus grande partie de la m�moire utilis�e par xv n'est jamais acc�d�e. C'est �galement vrai dans le cas d'un �diteur multi-fen�tres o� seule une page � la fois est active. Ces programmes - s'ils sont con�us correctement - respectent rigoureusement le principe de localit�, et la plus grande partie de la place qu'ils occupent peut rester dans la swap sans qu'on observe de diminution substantielle des performances. On peut suspecter que ce chiffre de 25 % datant de l'�poque de la ligne de commande n'est plus vrai pour les logiciels modernes dot�s d'une IHM graphique et capables d'�diter simultan�ment plusieurs documents, mais je n'ai connaissance d'aucune donn�e r�cente permettant d'actualiser ces chiffres.

En r�sum�, si on dispose de 16 Mo de RAM, un configuration minimale peut se passer de swap, et attribuer plus de 48 Mo � la swap est sans doute inutile. L'appoint exact de m�moire requise d�pend des applications qui tournent sur la machine (qu'est-ce que vous vous �tiez imagin� ?).

3.3 O� positionner ma zone swap ?

• Les mouvements m�caniques sont lents, et les mouvements �lectroniques rapides. Les disques r�cents on plusieurs t�tes de lecture. Permuter entre les t�tes qui se trouvent sur la m�me piste est rapide, puisque c'est purement �lectronique. Par contre changer de piste est lent, puisque �a implique un mouvement des t�tes. Par cons�quent si vous avez un disque avec plusieurs t�tes de lecture et un autre qui en a moins, les autres param�tres �tant identiques, le disque qui a le plus de t�tes de lectures sera le plus rapide. D�couper la zone swap en la r�partissant sur les disques acc�l�rera aussi la vitesse d'acc�s.
• Les anciens disques ont le m�me nombre de secteurs sur toutes les pistes. Avec ce type de disque, la vitesse maximum est g�n�ralement obtenue en pla�ant la zone swap au milieu du disque, si on part du principe que la t�te de lecture devra se d�placer d'une piste quelconque vers l'emplacement physique de la zone swap.
• Les disques plus r�cents utilisent le ZBR (bit d'enregistrement de zone). Les pistes externes contiennent un plus grand nombre de secteurs. Pour une vitesse de rotation constante, on obtient donc un bien meilleur rendement pour les pistes externes que pour les pistes internes. Placer de pr�f�rence votre zone swap sur les pistes les plus rapides.
• Mais bien s�r, la t�te de lecture n'est pas anim�e de mouvement al�atoires. Si le milieu du disque tombe entre une partition /home en acc�s constant et une partition d'archivage presque jamais utilis�e, vous feriez mieux de placer votre zone swap au milieu de la partition /home, pour limiter l'amplitude de mouvement des t�tes de lecture. Le mieux, dans ce cas, serait m�me de placer votre zone swap sur un autre disque, moins activement utilis�.

En r�sum� : Placez votre zone swap sur un disque rapide �quip� de plusieurs t�tes de lecture et qui n'est pas trop accapar� par d'autres t�ches. Si vous avez plusieurs disques, r�partissez la zone swap sur tous ces disques, m�me si leurs contr�leurs sont diff�rents.

Encore mieux : Achetez plus de RAM.

3.4 Quelques bricoles au sujet des syst�mes de fichiers et de la fragmentation

L'espace disque est administr� par le syst�me d'exploitation en unit�s de blocs et fragments de blocs. En ext2, fragments et blocs doivent �tre de la m�me taille, aussi nous limiterons la discussion aux blocs.

Les fichiers ont des tailles tr�s variables qui ne co�ncident pas n�cessairement avec la fin d'un bloc. Par cons�quent, pour chaque fichier, un partie du dernier bloc est gaspill�e. Supposons que la taille des fichiers soit al�atoire, il y a en moyenne un demi-bloc perdu pour chaque fichier pr�sent sur le disque. Dans son livre "Operating systems", Tanenbaum appelle �a la "fragmentation interne".

On peut d�duire le nombre de fichiers pr�sents sur le disque � partir du nombre d'inodes allou�s. Par exemple sur mon disque :

---

# df -i
Filesystem           Inodes   IUsed   IFree  %IUsed Mounted on
/dev/hda3              64256   12234   52022    19%  /
/dev/hda5              96000   43058   52942    45%  /var

---

Il y a donc environ 12000 fichiers sur / et pr�s de 44000 sur /var. Pour des blocs d'une taille de 1 Ko, � peu pr�s 6+22 = 28 Mo d'espace disque sont perdus dans les derniers blocs des fichiers. Si j'avais choisi des blocs d'une taille de 4 Ko, j'aurais perdu 4 fois plus de place.

Les transferts de donn�es sont plus rapides avec de grands tron�ons contigus de donn�es. C'est pourquoi l'ext2 s'efforce de pr�-allouer l'espace en unit�s de 8 blocs contigus pour les fichiers en cours d'�criture. L'espace pr�-allou� non utilis� est lib�r� lors de la fermeture du fichier, ainsi il n'y a pas de gaspillage.

Un rangement non contigu des blocs dans un fichier est pr�judiciable pour les performances, du fait qu'on acc�de g�n�ralement aux fichiers de mani�re s�quentielle. Cela oblige le syst�me d'exploitation � d�couper les acc�s disque et le disque � d�placer la t�te de lecture. On appelle cela la "fragmentation externe", ou simplement la "fragmentation", qui est un probl�me courant avec les syst�mes de fichiers de type DOS.

ext2 utilise plusieurs strat�gies afin d'�viter la fragmentation externe. Normalement la fragmentation n'est pas un gros probl�me en ext2, m�me avec des partitions tr�s utilis�es, comme une file d'attente news. Bien qu'il existe un utilitaire de d�fragmentation des syst�mes de fichier ext2, personne ne l'utilise et il n'est pas � jour avec la derni�re version de ext2. Utilisez le si vous y tenez, mais � vos risques et p�rils.

Le syst�me de fichiers MS-DOS est r�put� pour sa gestion pathologique de l'espace disque. La conjugaison d'un cache tampon abyssal et de la fragmentation a des cons�quences tout � fait dommageables sur les performances. Les utilisateurs de DOS sont habitu�s � d�fragmenter leurs disques toutes les quelques semaines et certains ont m�me mis au point un rituel quasi religieux concernant la d�fragmentation. Aucune de ces habitudes ne devrait �tre transpos�e sous Linux et ext2. Le syst�me de fichiers natif de Linux n'a pas besoin de d�fragmentation en utilisation normale, ce qui inclut n'importe quelle condition du moment que 5 % de l'espace disque reste libre.

Le syst�me de fichiers MS-DOS est aussi r�put� pour perdre une grande quantit� d'espace disque en raison de la fragmentation interne. Pour des partitions d'une taille sup�rieure � 256 Mo, la taille des blocs DOS devient si importante qu'ils ne sont plus d'aucune utilit� (cela a �t� corrig� jusqu'� un certain point avec la FAT32).

ext2 ne force pas l'utilisation de grands blocs dans le cas de grand syst�mes de fichiers, � l'exception des tr�s grands syst�mes de fichier de l'ordre de 0.5 To (1 Tera-octet = 1024 Go) et plus, pour lesquels les blocs de petite taille deviennent inefficaces. Donc, contrairement au DOS, il n'est pas n�cessaire de d�couper les grands disques en plusieurs partitions pour conserver des blocs de petite taille. Dans la mesure du possible, utilisez la taille par d�faut de 1 Ko. Vous voudrez peut �tre exp�rimenter des blocs de 2 Ko pour certaines partitions, mais attendez vous � rencontrer quelques bugs peu courants : presque tout le monde utilise la taille par d�faut.

3.5 Dur�e de vie des fichiers et cycles de sauvegarde sont des crit�res dans le choix des partitions

Sous ext2, les d�cisions concernant le choix des partitions devraient �tre dirig�es par des consid�rations li�es aux sauvegardes, et de mani�re � �viter la fragmentation externe due aux dur�es de vie des diff�rents fichiers.

Les fichiers ont une dur�e de vie. Une fois cr��, un fichier restera un certain temps sur le syst�me avant d'�tre supprim�. La dur�e de vie des fichiers varie consid�rablement au sein du syst�me, et d�pend en partie du chemin d'acc�s du fichier. Par exemple, les fichiers pr�sents dans /bin, /sbin, /usr/sbin, /usr/bin ou quelqu'autre r�pertoire du m�me type ont une dur�e de vie tr�s longue : de nombreux mois, voire plus. Les fichiers pr�sents dans /home ont une dur�e de vie interm�diaire : � peu pr�s quelques semaines. Les fichiers pr�sents dans /var ont g�n�ralement une dur�e de vie courte : quasiment aucun fichier dans /var/spool/news ne restera plus de quelques jours, et dans /var/spool/lpd le temps de vie se mesure en minutes voire moins.

Pour sauvegarder, il peut �tre utile de s'assurer que la taille d'une sauvegarde journali�re reste inf�rieure � la taille du support de sauvegarde. Une sauvegarde journali�re peut �tre compl�te ou diff�rentielle.

Vous pouvez d�cider de conserver des tailles de partitions suffisamment petites pour tenir compl�tement sur un seul support de sauvegarde (auquel cas, faites des sauvegardes journali�res compl�tes). Dans tous les cas, la taille d'une partition devrait �tre telle que son "delta" journalier (tous les fichiers modifi�s) puisse tenir sur un seul support de sauvegarde (faites une sauvegarde diff�rentielle, et pr�voyez de changer le support pour la sauvegarde hebdomadaire/mensuelle compl�te).

Votre strat�gie de sauvegarde repose sur ces d�cisions.

Lorsque vous achetez et organisez de l'espace disque, pensez � mettre de cot� une somme suffisante pour les sauvegardes aff�rentes ! Des donn�es non sauvegard�es sont sans valeur ! Le co�t de reproduction des donn�es est de loin plus �lev� que celui de la sauvegarde, pour qui que ce soit !

Pour des raisons de performances, il est utile de conserver des fichiers ayant des dur�es de vie diff�rentes sur des partitions diff�rentes. De cette mani�re, les fichiers �ph�m�res de la partition .../news peuvent �tre tr�s lourdement fragment�s. Cela n'aura aucune incidence sur les performances des partitions / ou /home.

Hosting by: Hurra Communications GmbH
Generated: 2007-01-26 18:01:22