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.