Linux Partition Mini-HOWTO

Kristan Koehntopp, kris@koehntopp.de
Adaptation fran�aise : Rapha�l Gurlie, raphael@ibpc.fr et Guillaume Bertucat,
guillaume@ibpc.fr.

   Partition mini-HOWTO v 2.4, le 03 mars 1998
     _________________________________________________________________

   _Ce Mini-HOWTO de Linux d�crit comment pr�voir et organiser l'espace
   disque de votre syst�me Linux. Il traite des aspects mat�riels des
   disques, des partitions, de la taille et du positionnement des zones
   de swap, des syst�mes de fichiers, des types de syst�mes de fichiers
   ainsi que de th�mes apparent�s. L'objectif est de donner quelques
   notions fondamentales, pas les modes op�ratoires._
     _________________________________________________________________

1. Introduction

1.1 De quoi s'agit-il?

   Ceci est un Mini-HOWTO de Linux. Un Mini HOWTO est un court texte qui
   fait le point sur des questions relatives � l'installation et � la
   maintenance de Linux. C'est Mini, parce que tant le texte que le th�me
   trait� sont trop "petits" pour justifier un vrai HOWTO ou un livre. Un
   HOWTO ne constitue pas une r�f�rence : les pages "man" sont l� pour
   �a.

1.2 De quoi ne s'agit-il pas (et HOWTO apparent�s) ?

   Ce Mini-HOWTO de Linux explique comment pr�voir et organiser l'espace
   disque de votre syst�me Linux. Il traite des aspects mat�riels des
   disques, des partitions, de la taille et du positionnement des zones
   de swap, des syst�mes de fichiers, des types de syst�mes de fichiers
   ainsi que de th�mes apparent�s. L'objectif est de donner quelques
   notions fondamentales, aussi nous parlerons essentiellement de
   principes et non pas d'outils dans ce texte.

   Dans des circonstances id�ales, ce document devrait �tre lu avant
   votre premi�re installation, mais c'est sans doute peu r�aliste dans
   la plupart des cas. Les d�butants ont g�n�ralement d'autres probl�mes
   que d'optimiser l'organisation de leur disque. Par cons�quent, vous
   �tes probablement quelqu'un qui vient juste de finir l'installation de
   Linux, et qui maintenant se demande comment optimiser cette
   installation, ou comment �viter quelques d�plaisantes erreurs de
   calculs pour la prochaine fois. Bien s�r, j'esp�re que lorsqu'ils en
   auront fini avec ce document, certains voudront laisser tomber leur
   ancienne configuration pour une nouvelle installation. :-)

   Ce document se limite pour l'essentiel � la pr�vision et
   l'organisation de l'espace disque. Il ne d�crit pas l'utilisation de
   fdisk, LILO, mke2fs ou des programmes de sauvegarde. Il y a d'autres
   HOWTO qui traitent de ces probl�mes. Reportez-vous � la
   Liste-des-HOWTO de Linux pour obtenir les informations relatives aux
   diff�rents HOWTOs de Linux. La liste contient �galement les
   informations n�cessaires pour obtenir les documents eux-m�mes.

   Pour apprendre � estimer les besoins en taille et en vitesse pour les
   diff�rentes parties du syst�me de fichiers, reportez-vous au "Linux
   Multiple Disks Layout mini-HOWTO", de Gjoen Stein <gjoen@nyx.net>.

   Pour obtenir des informations et des instructions concernant les
   disques de plus de 1024 cylindres, reportez-vous au "Linux Large Disk
   Mini-HOWTO", de Andries Brouwer <aeb@cwi.nl>.

   Pour obtenir des instructions sur la mani�re de limiter l'espace
   disque allou� � chaque utilisateur, reportez-vous au "Linux Quota
   Mini-HOWTO", de Albert M.C. Tam <bertie@scn.org>

   Actuellement il n'y a pas de documentation g�n�rale sur la sauvegarde
   des disques, mais il existe un certain nombre de documents qui font le
   point sur des solutions sp�cifiques de sauvegarde. Reportez-vous au
   "Linux ADSM Backup Mini-HOWTO" de Thomas Koenig
   <Thomas.Koenig@ciw.uni-karlsruhe.de> pour obtenir des renseignements
   sur la mani�re d'int�grer Linux dans un environnement de sauvegarde
   IBM ADSM. Reportez-vous au "Linux Backup with MSDOS Mini-HOWTO" de
   Christopher Neufeld <neufeld@physics.utoronto.ca> pour obtenir des
   informations sur les sauvegardes Linux pilot�s par MSDOS.

   Pour obtenir des instructions sur la mani�re d'�crire et de soumettre
   un HOWTO, reportez-vous � la "Liste-des-HOWTO" de Linux de �ric Dumas
   <dumas@Linux.EU.Org>.

   Butiner dans /usr/src/linux/Documentation peut aussi se r�v�ler tr�s
   instructif. Les fichiers ide.txt et scsi.txt fournissent quelques
   informations fondamentales sur les propri�t�s de vos pilotes disque,
   et jeter un coup d'oeil � l'arborescence de votre syst�me de fichiers
   ne peut pas faire de mal.

2. Qu'est-ce qu'une partition ?

   Lorsque les disques durs pour PC ont �t� mis au point, on a rapidement
   cherch� � avoir la possibilit� d'installer plusieurs syst�mes
   d'exploitation, m�me si on ne disposait que d'un seul disque. Par
   cons�quent, il fallait un proc�d� permettant de diviser un seul disque
   physique en plusieurs disques logiques. Une partition, c'est justement
   cela : une section contigu� de blocs sur le disque dur, consid�r�e
   comme un disque totalement ind�pendant par la plupart des syst�mes
   d'exploitation.

   Il est bien �vident que les diff�rentes partitions ne doivent pas se
   recouvrir : un syst�me d'exploitation n'appr�ciera certainement pas
   qu'un autre OS install� sur la m�me machine �crase des donn�es
   importantes � cause d'un tel recouvrement. D'autre part, il ne devrait
   pas non plus y avoir de "trou" entre deux partitions adjacentes. Bien
   que ce ne soit pas nuisible en soi, vous g�cheriez une place pr�cieuse
   en laissant vides de tels espaces.

   Il n'est pas indispensable que le disque soit enti�rement partitionn�.
   Vous pouvez d�cider de laisser de la place � la fin du disque qui ne
   soit attribu�e � aucun de vos syst�mes d'exploitation. Par la suite,
   lorsque vous saurez quel syst�me vous utilisez le plus souvent, vous
   pourrez partitionner l'espace restant, et cr�er dessus un syst�me de
   fichier appropri�.

   Les partitions ne peuvent �tre ni d�plac�es, ni redimensionn�es sans
   d�truire le syst�me de fichiers qui s'y trouve. C'est pourquoi
   modifier la table de partition implique g�n�ralement de sauvegarder
   puis de restaurer tous les syst�mes de fichiers touch�s par cette
   op�ration. En fait il est assez facile de faire des d�g�ts
   irr�parables en repartitionnant, et vous devriez faire une sauvegarde
   int�grale de tous les disques de la machine en question avant m�me de
   penser � utiliser un utilitaire comme fdisk.

   Bon, � vrai dire, certaines partitions contenant certains types de
   syst�me de fichiers _peuvent_ �tre coup�es en deux sans perte de
   donn�es (si vous avez de la chance). Par exemple, il y a un utilitaire
   appel� fips pour couper en deux les partitions MS-DOS, ce qui permet
   de cr�er un espace pour installer Linux sans avoir � r�installer
   MS-DOS. Mais vous n'avez pas vraiment l'intention de jouer avec �a
   sans sauvegarder soigneusement tout ce qui ce trouve sur votre machine
   ?

2.1 Les sauvegardes sont importantes

   Pour les sauvegardes, les lecteurs de bandes sont vos amis. Ils sont
   rapides fiables et faciles � utiliser, ce qui permet de faire de
   fr�quentes sauvegardes, de pr�f�rence automatiquement, et sans
   s'emb�ter.

   Je tiens particuli�rement � insister sur les points suivants : je
   parle de vrais lecteurs de bandes, pas de cette daube de ftape pilot�e
   par le contr�leur du disque. Envisagez d'investir dans le SCSI : Linux
   supporte le SCSI de fa�on native. Vous n'aurez pas besoin de
   t�l�charger des pilotes ASPI. Vous ne perdrez pas non plus de
   pr�cieuses HMA sous Linux d�s que vous aurez install� votre contr�leur
   SCSI, vous n'aurez plus qu'� y ajouter vos disques durs, lecteur de
   bandes et lecteurs CDROM. Pas d'autres adresses I/O, plus besoin de
   jongler avec les IRQ, ni de s'inqui�ter des compatibilit�s
   ma�tre/esclave ou des niveaux PIO. En outre, un contr�leur SCSI
   appropri� vous donne de hautes performances I/O sans augmenter
   notablement la charge du CPU. M�me en cas de grande activit� du
   disque, vous pourrez constater de bons temps de r�ponse. Si vous
   envisagez d'utiliser un syst�me Linux comme un centre de distribution
   de news, ou si vous vous appr�tez � vous lancer dans le domaine des
   services d'acc�s � Internet, ne pensez m�me pas � un syst�me sans
   SCSI.

2.2 Noms et num�ros des p�riph�riques

   Le nombre de partitions sur un syst�me � base d'Intel � �t� limit�
   depuis le commencement : la table de partitions originale faisait
   partie int�grante du secteur d'amor�age, et la place pr�vue nous
   limitait � quatre partitions. Ces partitions sont maintenant appel�es
   partitions primaires. Lorsqu'il est devenu �vident que beaucoup
   avaient besoin de plus de quatre partitions sur leurs syst�mes, les
   partitions logiques ont �t� cr��es. Le nombre de partitions logiques
   n'est pas limit� : chaque partition logique contient un pointeur sur
   la suivante, et par cons�quent, vous disposez potentiellement d'une
   liste non limit�e de partitions.

   Pour des raisons de compatibilit�, l'espace occup� par les partitions
   logiques doit �tre comptabilis�. Si vous utilisez les partitions
   logiques, une des partitions primaires est donc not�e "partition
   �tendue" ; son bloc initial et son bloc final d�limitent l'espace
   occup� par les partitions logiques. Ceci signifie que l'espace
   attribu� pour toutes les partitions logiques doit �tre contigu. Il ne
   peut y avoir qu'une seule partition �tendue : aucun fdisk n'acceptera
   de cr�er plus d'une partition �tendue.

   Linux ne peut prendre en charge qu'un nombre limit� de partitions par
   disque. Ainsi avec Linux, vous disposez de 4 partitions primaires
   (dont 3 utilisables si vous utilisez les partitions logiques) et au
   mieux 15 partitions en tout sur un disque SCSI (63 en tout sur un
   disque IDE).

   Sous Linux, les partitions sont identifi�es par des fichiers
   p�riph�riques. Un fichier p�riph�rique est un fichier de type c (pour
   p�riph�rique "caract�re", les p�riph�riques qui ne font pas usage de
   la cache tampon) ou b (pour p�riph�rique "bloc", qui font usage de la
   cache tampon). Sous Linux, tous les disques sont repr�sent�s sous la
   forme de p�riph�riques blocs uniquement. Contrairement � d'autres
   Unix, Linux ne propose pas de version strictement caract�re des
   disques et de leurs partitions.

   Les seules choses importantes � retenir d'un fichier p�riph�rique sont
   ses num�ros de p�riph�rique, majeur et mineur, affich�s � la place de
   la taille du fichier :
       ______________________________________________________________

$ ls -l /dev/hda
brw-rw----   1 root     disk       3,   0 Jul 18  1994 /dev/hda
                                   ^    ^
                                   |    num�ro p�riph�rique mineur
                                   num�ro p�riph�rique majeur
       ______________________________________________________________

   Lorsqu'on acc�de au fichier p�riph�rique, le num�ro majeur d�termine
   quel pilote p�riph�rique va �tre appel� pour r�aliser l'op�ration
   d'entr�e/sortie. Cet appel est fait en prenant comme param�tre le
   num�ro mineur, et c'est l'affaire du pilote d'interpr�ter correctement
   ce num�ro mineur. La documentation du pilote d�crit g�n�ralement la
   mani�re dont il interpr�te ces num�ros mineurs. Pour les disques IDE,
   cette documentation se trouve dans
   /usr/src/linux/Documentation/ide.txt. Pour les disques SCSI, on
   s'attendrait � trouver la documentation dans
   /usr/src/linux/Documentation/scsi.txt, mais elle ne s'y trouve pas. Il
   peut �tre n�cessaire de consulter la source du pilote pour �tre s�r
   (/usr/src/linux/driver/scsi/sd.c:184-196). Heureusement, il y a la
   liste des noms et num�ros de p�riph�riques de Peter Anvin dans
   /usr/src/linux/Documentation/devices.txt; reportez vous dans cette
   liste � block devices, major 3, 22, 33, 34 pour les disques IDE, et
   major 8 pour les disques SCSI. Les num�ros majeurs et mineurs sont
   cod�s chacuns sur un bit, ce qui explique pourquoi le nombre de
   partition par disque est limit�.

   Par convention, les fichiers p�riph�riques ont un nom d�fini, et la
   plupart des utilitaires syst�me sont compil�s en ayant connaissance de
   ces noms. Ils s'attendent � ce que vos disques IDE s'appellent
   /dev/hd* et vos disques SCSI /dev/sd*. Les disques sont num�rot�s a,
   b, c et ainsi de suite, donc /dev/hda est votre premier disque IDE, et
   /dev/sda votre premier disque SCSI. Chaque p�riph�rique repr�sente un
   disque � part enti�re d�marrant au bloc un. �crire sur un de ces
   p�riph�riques avec les mauvais utilitaires d�truira l'enregistrement
   principal d'initialisation (MBR) et la table de partition, ce qui
   rendra toutes les donn�es de ce disque inutilisables, et le syst�me ne
   pourra plus d�marrer sur ce disque. Donc soyez s�rs de ce que vous
   faites, et encore une fois, sauvegardez avant de faire quoi que ce
   soit.

   Les partitions primaires sur le disques sont num�rot�es 1, 2, 3 et 4.
   Par cons�quent, /dev/hda1 est la premi�re partition primaire du
   premier disque IDE, et ainsi de suite. Les partitions logiques se
   voient attribuer les num�ros 5 et suivants; /dev/sdb5 est donc la
   premi�re partition logique du second disque SCSI.

   Chaque partition se voit attribuer deux adresses pour les blocs
   initial et final, ainsi qu'un type. Le type est un code num�rique (un
   bit) qui d�finit une partition pour un syst�me d'exploitation donn�.
   Pour la plus grande joie des experts, il n'existe pas vraiment de code
   unique d�finissant les diff�rents types de partition, aussi il y a
   toujours une possibilit� que deux syst�mes d'exploitation utilisent le
   m�me code pour des partitions de type diff�rent.

   Linux r�serve les codes 0x82 pour les partitions swap, et 0x83 pour
   les syst�mes de fichier "natif" (c'est � dire ext2 pour la plupart
   d'entre vous). Autrefois populaire et maintenant p�rim�, le syst�me de
   fichiers Linux/Minix utilisait le code 0x81 pour ses partitions. OS/2
   marque ses partitions du type 0x07, tout comme les NTFS de Windows NT.
   MS-DOS attribue plusieurs codes pour les diff�rentes FAT de ses
   syst�mes de fichier : on conna�t 0x01, 0x04 et 0x06. DR-DOS utilisait
   0x81 pour indiquer une partition FAT prot�g�e, ce qui g�n�rait un
   conflit avec les partitions Linux/Minix, mais ni l'une ni l'autre ne
   sont tr�s utilis�es maintenant. La partition �tendue qui sert de
   container pour les partitions logiques � le code 0x05.

   Les partitions sont cr��es et supprim�es avec l'utilitaire fdisk. Tout
   syst�me d'exploitation qui se respecte poss�de un fdisk, qui
   d'ailleurs est traditionnellement appel� fdisk (ou FDISK.EXE) dans
   quasiment tous les OS. Certains fdisk, dont celui du DOS, sont quelque
   peu limit�s pour g�rer les partitions d'autres syst�mes
   d'exploitation. Parmi ces limites, l'impossibilit� de prendre en
   compte tout ce qui est identifi� par un code de type �tranger,
   l'impossibilit� de prendre en compte plus de 1024 cylindres, et
   l'impossibilit� de cr�er ou m�me de reconna�tre une partition dont la
   fin ne co�ncide pas avec la borne d'un cylindre. Par exemple, le fdisk
   de MS-DOS ne peut pas supprimer les partitions NTFS, le fdisk de OS/2
   �tait r�put� pour "corriger" silencieusement les partition cr�es par
   le fdisk de Linux dont la fin ne co�ncidait pas avec une borne de
   cylindre, et tant le fdisk de MS-DOS que celui de OS/2 ont eu des
   probl�mes avec les disques de plus de 1024 cylindres (reportez-vous au
   "large-disk Mini-HOWTO" pour de plus amples d�tails sur ces disques).

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.

4. Un exemple

4.1 Un mod�le � suivre pour d�butant ambitieux

   Un mod�le courant propose la cr�ation des partitions /, /home et /var
   pour des raisons abord�es plus haut. Cela simplifie tant
   l'installation que la maintenance, et la diff�renciation est
   suffisante pour �viter les effets pervers des dur�es de vie
   diff�rentes. C'est aussi un bon mod�le en ce qui concerne la
   sauvegarde : personne ne se soucie de sauvegarder les files d'attente
   "news" et seulement quelques fichiers de /var peuvent �tre utilement
   sauvegard�s (comme /var/spool/mail). D'un autre cot�, / change tr�s
   peu souvent et peut n'�tre sauvegard� que ponctuellement (apr�s un
   changement de configuration), et sa taille relativement faible permet,
   pour la plupart des supports modernes, de faire une sauvegarde
   compl�te (pr�voyez de 250 � 500 Mo en fonctions des logiciels
   install�s). /home contient les pr�cieuses donn�es des utilisateurs et
   devrait �tre sauvegard� chaque jour. Certaines configurations
   pr�sentent un /home tr�s important et doivent par cons�quent faire
   appel au sauvegardes diff�rentielles.

   Certains syst�mes pr�voient une partition s�par�e pour /tmp, d'autres
   cr�ent un lien symbolique sur /var/tmp pour obtenir un r�sultat
   similaire (notez que cela peut affecter le mode "single user" pour
   lequel /var ne sera pas disponible, � moins de le cr�er ou de le
   monter manuellement) ; ou encore placez le sur disque RAM (comme c'est
   le cas sous Solaris). Cela tient /tmp s�par� de /, ce qui es une bonne
   id�e.

   Ce mod�le est tout � fait adapt� aux mises � jour ou aux
   r�installations : sauvez vos fichiers de configuration (ou la totalit�
   de /etc) dans un r�pertoire de /home, d�barrassez vous de /,
   r�installez et r�cup�rez votre ancienne configuration � partir du
   r�pertoire de sauvegarde sur /home.

5. Comment je m'y suis pris personnellement

   Un vieux 386/40 sur bus ISA tra�nait sur mon �tag�re depuis deux ans.
   J'avais l'intention de le transformer en un petit serveur non-X pour
   mon r�seau local.

   Voici comment je m'y suis pris : j'ai r�cup�r� ce 386 et l'ai dot� de
   16 Mo de RAM. J'y ai ajout� le disque le moins cher et le plus petit
   que j'ai pu trouver (800 MB), une carte Ethernet et une vieille
   Hercules parce que j'avais toujours le moniteur. J'ai install� Linux,
   ce qui m'a permis de disposer d'un serveur NFS, SMB, HTTP, LPD/LPR et
   NNTP familial ainsi que d'un routeur mail et d'un serveur POP3. Avec
   en plus une carte RNIS, cette machine me sert maintenant en plus de
   routeur TCP/IP et de pare-flamme.

   L'essentiel de l'espace disque sur cette machine est pass� dans les
   r�pertoires de /var, /var/spool/mail, /var/spool/news et
   /var/httpd/html. J'ai plac� /var sur un partition s�par�e, que j'ai
   cr��e suffisamment grande. Comme il n'y aura autant dire pas
   d'utilisateurs sur cette machine, je n'ai pas cr�� de partition home,
   et j'ai donc mont� /home depuis une autre station de travail via NFS.

   Une partition / de 250 Mo est amplement suffisante pour Linux sans X,
   dot� de quelques utilitaires locaux suppl�mentaires. Cette machine a
   16 Mo de RAM, mais elle est destin�e � piloter de nombreux serveurs.
   16 Mo de swap serait correct, 32 Mo l'abondance. Comme l'espace disque
   le permet, disons 32 Mo de swap. Conservons une partition MS-DOS de 20
   Mo. Comme j'ai d�cid� d'importer /home depuis une autre machine, les
   500+ Mo constitueront /var. C'est plus que suffisant pour un centre de
   distribution de news familial.

   Nous avons donc :
       ______________________________________________________________

Device     Mounted on                      Size
/dev/hda1  /dos_c                           25 MB
/dev/hda2  - (Swapspace)                    32 MB
/dev/hda3  /                               250 MB
/dev/hda4  - (Extended Container)          500 MB
/dev/hda5  /var                            500 MB

homeserver:/home /home                     1.6 GB
       ______________________________________________________________

   J'effectue les sauvegardes de cette machine via le r�seau en utilisant
   le lecteur de bande de homeserveur. Du fait que l'installation a �t�
   faite � partir d'un CDROM, je n'ai besoin de sauvegarder que quelques
   fichiers de /etc, mes fichiers *.tgz personnalis�s install�s
   localement sur /root/Source/Installed et /var/spool/mail ainsi que
   /var/httpd/html. Je copie chaque nuit ces fichiers dans un r�pertoire
   d�di� /home/backmeup sur homeserver, o� la sauvegarde r�guli�re de
   homeserver les r�cup�re.