%--------------------------------------------------------------------
\chapter{Utiliser les disques et les autres supports de stockage}
%--------------------------------------------------------------------

        \begin{chapterquote}
	Sur un disque vierge, personne ne vous entendra chercher.\\
        \end{chapterquote}

% the following metas need too much work for the next version
%
%	\meta copying a directory/disk verbatim
%
%	\meta disaster recovery: program to scan for ext2 superblocks
%
%	\meta explain lost+found; how to fix a filesystem; what to do when
%	there is a bad block; identifying the file that has the bad block
%	
%	\meta chart that shows characteristics of various fs: max size,
%	max file size, usable as root, max name length, speed, support
%
%	\meta 
%	Recovering from a bad MBR or super block.
%	Manually remounting (ro->rw, rw->ro, when, why)
%	automounting
%	MD patches
%	Why does Linux read/write disk in background?
%	how to mount a dos disk so that everyone can access it?
%	supermount
%	ide disks map away bad sectors (until they're too many, then
%	use badblocks)
%	mounting: mountee root becomes mount point, e.g. permissions/ownership
%	linux has maximum of 15 partitions (not inherent in partition
%		scheme!)
%	max ext2 part size is 2TB, file 2 GB

        \noindent
	Lorsque vous installez ou mettez à jour votre système, vous avez besoin de faire un peu de travail sur
vos disques. Vous devez créer des systèmes de fichiers pour y stocker vos données et réserver de la place pour
les différentes parties de votre système. 
   
        Ce chapitre décrit toutes ces activités initiales. D'habitude, lorsque votre système est en place, 
vous n'avez plus besoin de refaire ce travail, sauf pour les disquettes. Vous aurez besoin de revenir à ce chapitre si vous ajoutez un
nouveau disque dur ou si vous voulez régler de façon plus fine votre utilisation des disques.

        Les t\^aches de base, dans l'administration des disques sont~:
	%%
        \begin{itemize}
        \item
        Formater le disque. Cette opération le prépare à \^etre utilisé, notamment en vérifiant les
secteurs défectueux. (Le formatage n'est, actuellement, plus nécessaire pour la majorité des disques durs.)

        \item
 	Partitionner un disque dur. Une des raisons du partitionnement est qu'il permet de faire cohabiter plusieurs systèmes 
d'exploitation différents sur le m\^eme disque. Une autre raison est qu'il permet de séparer les fichiers des utilisateurs
des fichiers systèmes, ce qui simplifie les sauvegardes et protège les fichiers systèmes d'une altération éventuelle.

        \item
        Créer un système de fichiers (d'un type reconnu) sur chaque disque ou partition. Un disque ne veut rien dire
pour Linux tant que l'on n'a pas créé un système de fichiers ; quand c'est fait, les fichiers peuvent \^etre créés et
accédés sur ce disque.

        \item
	Monter les différents systèmes de fichiers afin de former une seule arborescence de répertoires, soit
automatiquement, soit manuellement, selon les besoins. (Les systèmes de fichiers montés manuellement doivent
généralement \^etre démontés manuellement.)

        \end{itemize}

	Le chapitre~\ref{chap:mem} contient des informations concernant la mémoire virtuelle et le cache disque, informations
dont on doit tenir compte lorsqu'on utilise les disques.

        Ce chapitre explique ce qu'il faut savoir sur les disques durs, les disquettes, les CD-ROM's, et les lecteurs
de bandes.

\section{Deux types de dispositifs}

	UNIX, et donc Linux, reconna\^\i t deux types de dispositifs~: les périphériques à accès direct par blocs (comme
les disques), et les périphériques caractères (comme les bandes et les liaisons séries), dont certains
peuvent \^etre à accès direct et d'autres à accès séquentiel. Chaque périphérique supporté est représenté dans le
système de fichiers par un \defin{fichier pilote de périphérique}.  Lorsqu'on lit ou écrit dans un tel fichier, les données
proviennent du, ou vont dans, le périphérique qu'il représente. De cette façon, on n'a pas besoin de 
programmes spéciaux (ni de méthodes spéciales de programmation des applications, comme le masquage des
interruptions, ou l'interro\-ga\-tion des ports séries) pour accéder aux périphériques ; par exemple, pour envoyer un
fichier à l'imprimante, il suffit d'écrire~:
		%
		\begin{tscreen}
\verb|$| {\sl cat filename $>$ /dev/lp1} \\ 
\verb|$|
		\end{tscreen}
		%
        et le contenu du fichier est imprimé (le fichier doit, bien s\^ur, \^etre sous un format reconnu par
l'imprimante). Cependant, ce ne serait pas une bonne idée de permettre à plusieurs personnes d'imprimer leurs
fichiers au m\^eme instant avec cette méthode ; pour éviter cela, on utilise généralement un programme spécial 
pour imprimer les fichiers (normalement \cmd{lpr}). Ce programme s'assure qu'un seul fichier sera imprimé
à la fois, et enverra automatiquement les données à l'imprimante dès qu'elle a fini avec le document précédent. 
La plupart
des périphériques utilisent une méthode similaire. En fait, on a rarement besoin de se préoccuper des fichiers pilotes.

	Comme les périphériques sont considérés comme des fichiers dans le système de fichiers (dans le
répertoire \fn{/dev}), il est facile de voir quels fichiers pilotes existent, en utilisant
	\cmd{ls} ou tout autre commande adéquate. Dans ce qu'affiche \cmd{ls -l}, la première colonne contient le
type du fichier et ses permissions. Par exemple, visualiser un pilote série donne, sur mon système~:
		%
		\begin{tscreen}
\verb|$| {\sl ls -l /dev/cua0} \\
\verb|crw-rw-rw-   1 root     uucp       5,  64 Nov 30  1993 /dev/cua0| \\
\verb|$| 
		\end{tscreen}
		%
	Le premier caractère de la première colonne, i.e. `{\tt c}' dans
	{\tt crw-rw-rw-}, indique à un utilisateur averti le type du fichier, ici un périphérique caractère. Pour les
fichiers ordinaires, ce premier caractère est `{\tt -}', pour les répertoires c'est `{\tt d}', et pour les
périphériques bloc `{\tt b}' ; voir la page sur	\cmd{ls} dans le manuel en ligne pour plus d'informations.

	On notera, qu'en général, tous les fichiers pilotes existent m\^eme si le périphérique correspondant 
n'est pas installé. Donc, si vous avez un fichier \fn{/dev/sda}, cela ne signifie pas que vous ayez un
disque dur SCSI. Disposer de tous les fichiers pilotes rend les programmes d'installation plus simples, et
facilite l'ajout d'un nouveau matériel (il n'y a pas besoin de rechercher les paramètres corrects pour créer les
fichiers pilotes pour le nouveau périphérique).

\section{Disques durs}

	Cette sous-section introduit les termes concernant les disques durs. Si vous les connaissez déjà ces termes et
tous les concepts, vous pouvez ne pas la lire.

	La figure~\ref{fig:hd-schematic} montre une image schématique des parties importantes d'un disque dur. Un
disque dur est composé d'un ou plusieurs \defin{plateaux} circulaires\footnote{Les plateaux sont composés d'un
matériau rigide (par exemple, de l'aluminium) d'où le nom de disque dur}, dont l'une ou les deux surfaces sont 
recouvertes d'un matériau magnétique utilisé pour enregistrer les données. Il y a une \defin{t\^ete de lecture-écriture}
par surface qui examine, ou modifie, les données enregistrées. Les plateaux tournent autour d'un axe commun, à une
vitesse de l'ordre de 3600 tours par minute, bien que les disques hautes performances aient des vitesses encore
supérieures. Les t\^etes se déplacent radialement par rapport aux plateaux ; ce mouvement, combiné avec la
rotation des plateaux permet aux t\^etes d'accéder à toutes les parties des surfaces.

	Le processeur (CPU) et le disque communiquent via un \defin{contr\^oleur disque}. Cela dispense le reste
du système de savoir comment utiliser le disque puisque les contr\^oleurs des différents types de disques utilisent
la m\^eme interface vers le reste de l'ordinateur. Ainsi, l'ordinateur peut simplement dire
<< Hé, le disque : donne-moi ce que je veux >>, au lieu de longues et complexes séries de signaux
électriques pour déplacer les t\^etes au bon endroit, d'attendre que la position correcte vienne sous la t\^ete et
de faire tous les autres trucs déplaisants nécessaires. (En réalité, l'interface avec le contr\^oleur est
plut\^ot compliquée, mais bien moins que si elle n'existait pas.) Le contr\^oleur peut remplir aussi d'autres
fonctions comme << cacher >> le disque ou remplacer automatiquement un secteur défectueux.

	La description ci-dessus suffit généralement pour comprendre le matériel. Il y a aussi une foule
d'autres choses, comme le moteur qui fait tourner les plateaux et déplace les t\^etes, et l'électronique
qui commande les opérations des parties mécaniques, mais tout ceci n'est pas nécessaire pour comprendre le
principe de fonctionnement d'un disque dur.

	Les surfaces sont généralement divisées en anneaux concentriques, appelés
	\defin{pistes}, et celles-ci sont à leur tour divisées en \defin{secteurs}.
	Ce découpage est utilisé pour spécifier les emplacements sur le disque et pour permettre l'allocation
d'espace disque aux fichiers. Pour trouver un emplacement donné sur le disque dur, on peut dire~:
<< surface 3, piste 5, secteur 7 >>. En général, le nombre de secteurs est le m\^eme pour toutes les pistes, mais
certains disques durs en mettent plus dans les pistes extérieures (tous les secteurs ont la m\^eme taille
physique, et donc on peut en mettre plus dans les pistes extérieures qui sont plus longues). Typiquement, un
secteur contient 512~octets de données. Le disque lui-m\^eme ne peut gérer des volumes de données inférieurs 
à un secteur. 
		\begin{figure}[thb]
		\begin{center}
		\includegraphics{disks/hd-schematic.ps}
		\end{center}
		\caption{Représentation schématique d'un disque dur}
		\label{fig:hd-schematic}
		\end{figure}

	Chaque surface est divisée en pistes (et en secteurs) de la m\^eme façon. Ceci signifie que lorsque la t\^ete 
d'une surface est sur une piste, les t\^etes des autres surfaces sont aussi sur les pistes correspondantes. Toutes
ces pistes prises ensemble forment un \defin{cylindre}.  Cela prend du temps pour déplacer les t\^etes
d'une piste (cylindre) à une autre, donc en plaçant les données souvent accédées ensemble (par exemple, un
fichier) de façon à ce qu'elles soient sur le m\^eme cylindre, on n'a plus besoin de déplacer les t\^etes pour
tout lire. Ceci accro\^\i t les performances. Il n'est pas toujours possible de placer les données de cette
façon ; les fichiers qui sont stockés en plusieurs endroits du disque sont dits	\defin{fragmentés}.

	Le nombre de surfaces (ou de t\^etes, ce qui est la m\^eme chose), de cylindres et de secteurs varie beaucoup ;
la spécification de chacun de ces nombres est appelée \defin{géométrie} d'un disque dur. La géométrie est
généralement stockée dans une mémoire spéciale, sauvegardée par batterie et appelée
\defin{RAM CMOS}, que le système d'exploi\-ta\-tion peut consulter au moment du lancement du système ou
lors de l'initialisation du pilote.

	Malheureusement, le BIOS\footnote{Le BIOS est un programme stocké en ROM. Il s'occupe, entre autres, des
étapes initiales du lancement du système.} possède une limitation dans sa conception, qui interdit 
de spécifier un numéro de piste supérieur à 1024 dans la RAM CMOS, ce qui est insuffisant pour un gros disque.
Pour contourner cela, le contr\^oleur du disque dur ment à propos de la géométrie, et \defin{traduit les
adresses} données par l'ordinateur en quelque chose qui correspond à la réalité. Par exemple, un disque dur peut avoir
8 t\^etes, 2048 pistes, et 35 secteurs par piste\footnote{Ces nombres sont purement imaginaires.}. Son
contr\^oleur peut mentir à l'ordinateur et prétendre qu'il a 16 t\^etes, 1024 pistes et 35 secteurs par piste,
n'excédant ainsi pas la limite sur les pistes, et traduire les adresses que l'ordinateur lui donne en divisant
par 2 le numéro de t\^ete et en doublant le numéro de piste. En réalité, le calcul peut \^etre plus compliqué car
les nombres ne sont pas aussi pratiques qu'ici (mais, encore une fois, les détails ne sont pas nécessaires pour 
comprendre le principe). Cette traduction modifie la vue qu'a le système d'exploitation de l'organisation du disque,
rendant ainsi impraticable l'astuce consistant à mettre toutes les données sur un seul cylindre pour améliorer
les performances. 

	La traduction n'intervient que pour les disques IDE. Les disques SCSI utilisent un numéro de secteur
séquentiel (i.e. le contr\^oleur traduit un numéro séquentiel de secteur en un triplet t\^ete, cylindre et secteur), 
et une méthode complètement différente pour les échanges entre le CPU et le contr\^oleur. Les disques SCSI sont
donc isolés du problème. On notera, toutefois, que l'ordinateur peut quand m\^eme ne pas conna\^\i tre la géométrie réelle d'un
disque SCSI.

	Puisque Linux ne conna\^\i t souvent pas la géométrie réelle d'un disque, ses systèmes de fichiers n'essaient
m\^eme pas de garder les fichiers dans un seul cylindre. Au lieu de ça, il essaie d'assigner des secteurs 
consécutifs aux fichiers, ce qui donne presque toujours des performances similaires. La question est encore
compliquée par les caches du contr\^oleur et les recherches anticipées qu'il fait automatiquement.

	Chaque disque dur est représenté par un fichier pilote de périphérique distinct.
	Il peut (généralement) n'y avoir que deux ou quatre disques durs IDE. Ils sont connus comme
	\fn{/dev/hda}, \fn{/dev/hdb},
	\fn{/dev/hdc}, et \fn{/dev/hdd}, respectivement.  Les disques durs SCSI
	sont connus comme \fn{/dev/sda}, \fn{/dev/sdb}, et ainsi de suite.
        Des conventions similaires existent pour nommer les autres types de disque durs ; voir~\cite{device-list} 
pour plus d'informations.
	On notera que les fichiers pilotes des disques durs donnent accès au disque entier, sans tenir compte des
partitions (qui seront étudiées plus loin), et qu'il est facile de semer la pagaille dans les partitions ou les
données si l'on n'y prend pas garde. Les fichiers pilotes des disques sont généralement uniquement utilisés pour
accéder au << master boot record >> (qui sera aussi étudié plus loin).

\section{Disquettes}

	Une disquette consiste en une membrane souple recouverte sur l'une ou ses deux faces par une
substance magnétique identique à celle des disques durs. Une disquette ne possède pas de t\^ete de lecture-écriture, 
celle-ci fait partie du lecteur. Une disquette correspond à un plateau de disque dur, mais elle est amovible et un
lecteur peut \^etre utilisé pour accéder à différentes disquettes, alors qu'un disque dur est une unité indivisible.

	Comme un disque dur, une disquette est divisée en pistes et secteurs (et les deux pistes correspondantes sur
les deux faces de la disquette forment un cylindre), mais il y en a beaucoup moins que sur un disque dur.

	Un lecteur de disquettes peut généralement utiliser plusieurs types différents de disquettes ; par exemple,
	un lecteur $3{1\over 2}$ pouces peut utiliser à la fois des disquettes de 720~ko et des disquettes de
	1,44~Mo.  Puisque le lecteur doit fonctionner de façon légèrement différente et que le système doit
savoir la taille de la disquette, il y a beaucoup de fichiers pilotes pour les disquettes, un par combinaison possible
de lecteur et de type de disquette.
	Ainsi, \fn{/dev/fd0H1440} est le premier lecteur (\texttt{fd0}),
	qui doit \^etre un lecteur $3{1\over 2}$ pouces,
	utilisant une disquette $3{1\over 2}$ pouces, haute densité (\texttt{H}) d'une taille
	de 1440~ko (\texttt{1440}), i.e., une disquette classique $3{1\over 2}$ pouces HD.
	Pour plus d'informations sur les conventions des noms des pilotes disquettes, voir~\cite{device-list}.

	Les noms des lecteurs de disquettes sont compliqués et Linux a donc un type spécial de pilote disquette qui
détermine automatiquement le type de la disquette qui est dans le lecteur. Il fonctionne en essayant de lire le
premier secteur de la disquette venant d'\^etre insérée en utilisant les différents formats de disquettes jusqu'à
ce qu'il trouve le bon. Naturellement, il faut que la disquette soit formatée. Les pilotes automatiques sont
nommés \fn{/dev/fd0}, \fn{/dev/fd1}, etc.

	Les paramètres que le pilote automatique utilise pour accéder à une disquette peuvent aussi \^etre positionnés
en utilisant le programme \cmd{setfdprm}.  Ceci peut \^etre utile si l'on utilise des disquettes qui ne correspondent
pas aux tailles habituelles, par exemple si elles ont un nombre inhabituel de secteurs, ou si la détection
automatique échoue et que le fichier pilote adéquat n'existe pas.

	Linux peut gérer un grand nombre de formats de disquettes non standard en plus des formats standards. Certains
d'entre eux nécessitent l'utilisation de programmes de formatage spéciaux. Nous passerons sur ces types de disquettes
pour l'instant, mais entre temps vous pouvez examiner le fichier \fn{/etc/fdprm}.  Il spécifie les valeurs reconnues
par \cmd{setfdprm}.

	Le système d'exploitation doit savoir quand une disquette a été changée dans un lecteur, pour, par
exemple, éviter d'utiliser des données d'une disquette précédente qui seraient encore dans le cache. Malheureusement, la ligne du signal utilisé
pour cela est souvent coupée, voire pire. Ceci ne se remarque pas toujours lorsqu'on utilise le lecteur à partir
de MS-DOS. Si vous avez des problèmes bizarres en utilisant les disquettes, cela peut en \^etre la raison. La seule 
façon de corriger ce problème est de réparer le lecteur.

\section{CD-ROMs}

	Un lecteur de CD-ROM utilise un disque optique recouvert de plastique. L'infor\-ma\-tion est enregistrée à la
surface du disque\footnote{c'est à dire la surface à l'intérieur du disque, sur le disque de métal à 
l'intérieur de l'enveloppe plastique.} sous la forme de petits << trous >> alignés selon une spirale partant du centre 
vers le bord. Le lecteur dirige un faisceau laser sur cette spirale pour lire le disque. Quand le laser rencontre
un trou, il est réfléchi d'une certaine façon ; quand il rencontre la surface plane, il est réfléchi d'une autre façon.
Cela facilite le codage des bits, et donc de l'information. Le reste est facile, plut\^ot mécanique.

	Les lecteurs de CD-ROM sont lents, comparés aux disques durs. Alors qu'un disque dur typique a un temps d'accès moyen inférieur à 15 millisecondes, un lecteur de CD-ROM rapide a des temps d'accès de l'ordre du dixième de seconde. Le
taux actuel de transfert des données est plut\^ot faible, de l'ordre de la centaine de kilo-octets par secondes. 
Cette lenteur fait que les lecteurs de CD-ROM ne sont pas aussi agréables à utiliser que les disques durs (certaines
distributions Linux fournissent des systèmes de fichiers pré-installés sur CD-ROM, ce qui évite d'avoir à copier
les fichiers sur le disque dur et facilite l'installation en économisant beaucoup d'espace disque). Pour
installer de nouveaux logiciels, les CD-ROMs sont très bien puisqu'une vitesse élevée n'est pas essentielle pour
une installation.

	Il existe plusieurs façons d'organiser les données sur un CD-ROM. La plus populaire est spécifiée par le
standard international ISO~9660. Ce standard décrit un système de fichier très réduit, plus spartiate encore que
celui de MS-DOS. D'un autre coté, il est si réduit que tout système d'exploitation devrait \^etre capable de 
l'adapter à son propre système natif.

	Pour une utilisation UNIX normale, le système de fichier ISO~9660 n'est pas utilisable, une extension
au standard a donc été développée. Elle porte le nom d'extension Rock Ridge. Rock Ridge autorise des noms de
fichiers plus longs, des liens symboliques et beaucoup d'autres facilités, permettant de considérer un CD-ROM 
plus ou moins comme n'importe quel système de fichiers UNIX. Encore mieux, un système de fichiers
Rock Ridge reste un système ISO~9660, ce qui lui permet d'\^etre utilisé par des systèmes non UNIX.
Linux supporte les extensions ISO~9660 et Rock Ridge, elles sont reconnues et utilisées automatiquement.

	Cependant, le système de fichiers ne représente que la moitié du chemin. La plupart des CD-ROMs contiennent des
données qui nécessitent un programme spécial pour \^etre accessibles, et la plupart de ces programmes ne fonctionnent
pas sous Linux (sauf, peut-\^etre, sous dosemu, l'émulateur MS-DOS de Linux).

	Un lecteur de CD-ROM est accédé via le fichier pilote correspondant. Il y a plusieurs façons de connecter un
lecteur à l'ordinateur~: via une interface SCSI, via une carte son, ou via une interface EIDE. Les modifications
matérielles à réaliser pour cela sortent du contexte de ce livre, mais le type de connexion décide du
fichier pilote. Voir~\cite{device-list} pour des éclaircissements.

\section{Bandes}

	Un lecteur de bande utilise une bande identique\footnote{Mais complètement différente, bien s\^ur.} à
celle des
cassettes utilisées pour la musique. Une bande est séquentielle par nature, ce qui signifie que, pour accéder à une
partie de celle-ci, on doit d'abord passer sur toutes les parties qui la précèdent. Un disque peut \^etre accédé
directement~: on peut sauter directement à toute partie du disque. L'accès séquentiel des bandes font qu'elles
sont lentes.

	D'un autre coté, les bandes sont relativement peu chères à faire puisqu'elles n'ont pas besoin d'\^etre
rapides. Elles peuvent aussi \^etre très longues et ainsi contenir un grand volume de données. Tout cela les
rend particulièrement adaptées pour des choses comme l'archivage et les sauvegardes, qui ne nécessitent pas de
vitesses rapides mais bénéficient des faibles co\^uts et des grandes capacités de stockage.

\section{Formatage}

	Le \defin{formatage} consiste à écrire des marques sur le support magnétique qui sont utilisées pour 
délimiter les pistes et les secteurs. Avant qu'un disque soit formaté, sa surface magnétique est un mélange de
signaux magnétiques. Lorsqu'il est formaté, de l'ordre est apporté au chaos, essentiellement en traçant des
lignes où iront les pistes, et où elles seront divisées en secteurs. Les vrais détails ne sont pas exactement 
ceux-ci mais cela n'a pas d'importance. Ce qui est important c'est qu'un disque ne peut \^etre utilisé tant qu'il
n'a pas été formaté.

	La terminologie est un peu confuse~: en MS-DOS, le mot formatage est utilisé pour couvrir aussi la
création d'un système de fichier (qui sera décrite plus tard). Là, les deux traitements sont souvent
combinés, surtout pour les disquettes. Quand une distinction s'avère nécessaire, le vrai formatage est appelé
\defin{formatage de bas niveau} tandis que la création du système de fichiers est appelée \defin{formatage de
haut niveau}. Dans les milieux UNIX, les deux sont appelés formatage et création du système de fichiers, ce sont les
termes que nous utiliserons donc dans ce livre.  

Pour les disques IDE, et pour certains disques SCSI, le formatage est maintenant réalisé en usine et n'a pas
besoin d'\^etre répété ; par conséquent, la plupart des gens ne s'en préoccupe pas. En fait, formater un disque dur
peut le rendre moins performant, par exemple parce qu'un disque a besoin d'\^etre formaté d'une façon très
particulière pour permettre le remplacement automatique des secteurs défectueux.

	Les disques ayant besoin d'\^etre formatés, ou pouvant \^etre souvent reformatés, nécessitent en tous cas
un programme spécial car l'interface vers la logique de formatage du disque est différente d'un disque à l'autre.
Souvent, le programme de formatage est, soit sur le BIOS, soit fourni comme un programme MS-DOS ; aucun
de ceux-ci ne peut-\^etre utilisé facilement sous Linux. 

	Pendant le formatage, on peut rencontrer des endroits défectueux sur le disque. Ils sont appelés
\defin{blocs défectueux} ou \defin{secteurs défectueux} et sont quelques fois gérés par le lecteur lui-m\^eme, mais,
m\^eme en ce cas, certaines choses doivent \^etre faites pour éviter d'utiliser ces parties du disque. La logique
s'occupant de ça est intégrée au système de fichiers ; la façon d'ajouter l'information au système de
fichiers est décrite ci-dessous. On peut aussi créer une petite partition qui ne ferait que couvrir la
partie défectueuse du disque ; cette approche peut \^etre bonne si la partie défectueuse est très importante,
car les systèmes de fichiers peuvent quelquefois avoir des problèmes avec de grosses  zones défectueuses.

	Les disquettes sont formatées avec \cmd{fdformat}.  On donne le fichier pilote de disquettes  en 
paramètre. Par exemple, la commande suivante formaterait une disquette haute densité, de $3{1\over 2}$ 
pouces dans le premier lecteur~:
		%
		\begin{tscreen}
\verb|$| {\sl fdformat /dev/fd0H1440} \\
\verb|Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB.| \\
\verb|Formating ... done| \\
\verb|Verifying ... done| \\
\verb|$ |
		\end{tscreen}
		%
	
On notera que si l'on veut utiliser le pilote automatique (\fn{/dev/fd0}), on {\em doit} d'abord positionner les
paramètres du périphérique avec	\cmd{setfdprm}.  Pour réaliser la m\^eme chose que ci-dessus, on devrait faire ce
qui suit~:
		%
		\begin{tscreen}
\verb|$| {\sl setfdprm /dev/fd0 1440/1440} \\
\verb|$| {\sl fdformat /dev/fd0} \\
\verb|Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB.| \\
\verb|Formating ... done| \\
\verb|Verifying ... done| \\
\verb|$ |
		\end{tscreen}
		%
	Il est habituellement plus pratique de choisir le fichier correspondant au type de la disquette. On notera
qu'il n'est pas souhaitable de formater une disquette pour qu'elle contienne plus d'information que pour ce 
pourquoi elle a été conçue.

	\cmd{fdformat} vérifiera aussi la disquette, i.e. recherchera les blocs défectueux. Il essaiera un
bloc défectueux plusieurs fois (on peut généralement l'entendre, le bruit du lecteur change perceptiblement).
Si la disquette est seulement défectueuse de façon marginale (à cause de la poussière sur les t\^etes de
lecture-écriture, certaines erreurs signalées n'en sont pas), \cmd{fdformat} ne se plaindra pas, par contre
une véritable erreur terminera le processus de vérification. Le noyau imprimera les messages pour chaque erreur
d'E/S qu'il trouve ; ceux-ci seront envoyés sur la console, ou, si \cmd{syslog} est utilisé, vers le fichier
\fn{/usr/adm/messages}.  \cmd{fdformat}
	lui-m\^eme n'indique pas où se trouve l'erreur (en règle générale, on s'en moque, les disquettes
sont suffisamment bon marché pour qu'on puisse se permettre d'en jeter une mauvaise systématiquement).
		%
		\begin{tscreen}
\verb|$| {\sl fdformat /dev/fd0H1440} \\
\verb|Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB.| \\
\verb|Formating ... done| \\
\verb|Verifying ... read: Unknown error| \\
\verb|$ |
		\end{tscreen}
		%

	La commande \cmd{badblocks} peut \^etre utilisée pour rechercher les blocs défectueux dans n'importe quel 
disque ou partition (y compris les disquettes). Elle ne formate pas le disque et peut donc \^etre utilisée
pour vérifier un système de fichiers existant. L'exemple suivant vérifie une disquette de $3{1\over 2}$ pouces 
qui possède deux blocs défectueux~:
		%
		\begin{tscreen}
\verb|$| {\sl badblocks /dev/fd0H1440 1440} \\
\verb|718| \\
\verb|719| \\
\verb|$ |
		\end{tscreen}
		%
	\cmd{badblocks} affiche les numéros des blocs défectueux qu'il trouve. La plupart des systèmes de
fichiers peuvent éviter de tels blocs. Ils maintiennent une liste des blocs défectueux connus qui est initialisée
lorsque le système de fichiers est créé et qui peut \^etre modifiée par la suite. La recherche initiale des
blocs défectueux peut \^etre faite par la commande \cmd{mkfs} (qui initialise le système de fichiers), mais
les vérifications ultérieures doivent \^etre faites avec
	\cmd{badblocks} et les nouveaux blocs doivent \^etre ajoutés avec 
	\cmd{fsck}.  Nous décrirons \cmd{mkfs} et \cmd{fsck} plus tard.

	Beaucoup de disques modernes notent automatiquement les blocs défectueux, et essaient de les réparer en utilisant
un bloc spécial et réservé à la place. Ceci est invisible du point de vue du système d'exploitation. Cette 
fonctionnalité est documentée dans le manuel du disque. M\^eme de tels disques peuvent échouer si le
nombre de blocs défectueux devient trop important, bien qu'alors il y ait de fortes chances pour que
le disque soit si abîmé qu'il devienne inutilisable.

\section{Partitions}

	Un disque dur peut \^etre divisé en plusieurs \defin{partitions}.
	Chaque partition fonctionne comme si elle était sur un disque dur séparé.
	L'idée est que si l'on a un seul disque dur et que l'on veut avoir, par exemple, deux systèmes d'exploitation
dessus, on peut diviser le disque en deux partitions. Chaque système d'exploitation utilise sa partition comme il
le désire et ne touche pas à celle de l'autre. De cette façon, les deux systèmes peuvent cohabiter pacifiquement
sur le m\^eme disque dur. Sans les partitions, on devrait acheter un disque dur pour chaque système d'exploitation.

	Les disquettes ne sont pas partitionnées. Il n'y a pas de raison technique à cela, mais étant données leurs 
petites capacités, les partitions seraient très rarement utiles. Les CD-ROMs aussi ne sont, en général, pas
partitionnés puisqu'il est plus facile de les utiliser comme un seul gros disque et qu'il y a rarement
besoin d'avoir plusieurs systèmes d'exploitation dessus.

\subsection{Le MBR, le secteur de boot et la table des partitions}

	L'information concernant le partitionnement d'un disque dur est stockée dans son premier secteur (c'est à 
dire le premier secteur de la première piste de la première surface du disque). Le premier secteur s'appelle le
	\defin{master boot record} (MBR) du disque ; c'est le secteur que le BIOS lit et exécute lorsque la machine
démarre.  Le master boot record contient un petit programme qui lit la table des partitions, vérifie quelle
partition est active (c'est à dire marquée comme étant bootable), et lit le premier secteur de cette
partition~: le \defin{secteur de boot} de la partition (le MBR est aussi un secteur de boot, mais il possède
un statut spécial et a donc un nom spécial). Ce secteur de boot contient un autre petit programme qui lit 
la première partie du système d'exploitation stocké sur cette partition (en supposant qu'elle soit bootable), puis 
le lance.

	Le schéma de partitionnement n'est pas intégré au matériel, ni m\^eme au BIOS. C'est seulement une
convention que beaucoup de systèmes d'exploitation suivent. Tous les systèmes ne la suivent pas, mais ils
constituent des exceptions. Certains systèmes d'exploitation supportent les partitions, mais occupent une
partition sur le disque dur et utilisent leur méthode de partitionnement interne à l'intérieur de cette 
partition. Ce dernier type coexiste sans problème avec d'autres systèmes (dont Linux) et ne nécessitent
aucune mesure particulière, mais un système d'exploitation qui ne supporte pas les partitions ne
peut pas cohabiter sur le m\^eme disque avec un autre système d'exploitation.

	Par précaution, il est préférable d'écrire la table des partitions sur une feuille de papier, ainsi, si elle
est endommagée, on ne perd pas tous ses fichiers. (Une table des partitions endommagée peut \^etre réparée avec
\cmd{fdisk}).  L'information nécessaire est donnée par la commande \cmd{fdisk -l}~:
		%
	\begin{tscreen}
\verb|$| \textsl{fdisk -l /dev/hda} \\
\verb|| \\
\verb|Disk /dev/hda: 15 heads, 57 sectors, 790 cylinders| \\
\verb|Units = cylinders of 855 * 512 bytes| \\
\verb|| \\
\verb|   Device Boot  Begin   Start     End  Blocks   Id  System| \\
\verb|/dev/hda1           1       1      24   10231+  82  Linux swap| \\
\verb|/dev/hda2          25      25      48   10260   83  Linux native| \\
\verb|/dev/hda3          49      49     408  153900   83  Linux native| \\
\verb|/dev/hda4         409     409     790  163305    5  Extended| \\
\verb|/dev/hda5         409     409     744  143611+  83  Linux native| \\
\verb|/dev/hda6         745     745     790   19636+  83  Linux native| \\
\verb|$|
	\end{tscreen}

\subsection{Partitions étendues et partitions logiques}

	Le schéma original de partitionnement pour les disques durs des PCs ne permettait que quatre partitions. Ceci 
s'est vite avéré trop limité, en partie parce que certains veulent avoir plus de quatre systèmes d'exploitation
(Linux, MS-DOS, OS/2, Minix, FreeBSD, NetBSD, ou
	Windows/NT, pour n'en citer que quelques uns), mais surtout parce qu'il est parfois judicieux d'avoir
plusieurs partitions pour un m\^eme système d'exploitation. Par exemple, sous Linux, l'espace de swap est généralement
 mis dans sa propre partition au lieu de se trouver dans la partition principale Linux pour des raisons de vitesse
(voir ci-dessous).

	Pour contourner ce problème de conception, les \defin{partitions étendues} ont été inventées.
	Cette ruse permet le partitionnement d'une \defin{partition primaire} en sous-partitions. La
partition primaire ainsi subdivisée est la partition étendue ; les sous-partitions sont des 
	\defin{partitions logiques}.  Elles se comportent comme les partitions primaires\footnote{Illogiques ?}, mais
sont créées différemment. Il n'y a pas de différence de rapidité entre elles.

	La structure des partitions d'un disque dur ressemble à la 
	figure~\ref{fig:hard-disk-layout}.  Le disque est divisé en trois partitions primaires, dont la seconde 
est divisée en deux partitions logiques. Une partie du disque n'est pas partitionnée du tout. Le disque dans son
ensemble et chaque partition primaire a son propre secteur de boot.

		\begin{figure}[thb]
		\begin{center}
		\includegraphics{disks/hd-layout.ps}
		%\include{hd-layout}
		\end{center}
		\caption{Exemple de partitionnement d'un disque dur.}
		\label{fig:hard-disk-layout}
		\end{figure}

\subsection{Types de partition}

	Les tables des partitions (une dans le  MBR, et les autres pour les partitions étendues) contiennent
un octet par partition qui identifie le type de celle-ci. Cela permet d'identifier le système d'exploitation qui
utilise cette partition, ou quel est son usage. Le but est d'éviter que deux systèmes d'exploitation
utilisent accidentellement la m\^eme partition. En réalité, les systèmes d'exploitation ne tiennent
pas vraiment compte de cet octet ; notamment Linux ne s'occupe pas du tout de lui. Pire, certains l'utilisent
de façon incorrecte ; notamment, certaines  versions de DR-DOS ignorent son bit de poids fort, alors que
d'autres en tiennent compte.

	Il n'existe pas d'organisme de standardisation pour décrire ce que chaque valeur de cet octet signifie, mais
certaines valeurs, communément acceptées, sont incluses dans le tableau~\ref{tab:partition-ids}.  La m\^eme liste est
disponible dans le programme \cmd{fdisk} de Linux.

\begin{table}[ht]
\begin{center}
\begin{tabular}{rl rl rl rl}
\hline
0 & Vide               & 40 & Venix 80286  & 94 & Amoeba BBT     \\
1 & FAT 12 bits DOS       & 51 & Novell?      & a5 & BSD/386        \\
2 & root XENIX          & 52 & Microport    & b7 & fs BSDI        \\
3 & usr XENIX            & 63 & GNU HURD     & b8 & swap BSDI      \\
4 & DOS 16-bit $<$32M   & 64 & Novell       & c7 & Syrinx         \\
5 & Etendue            & 75 & PC/IX        & db & CP/M           \\
6 & DOS 16-bit $\ge$32M & 80 & Ancien MINIX    & e1 & DOS access     \\
7 & OS/2 HPFS           & 81 & Linux/MINIX  & e3 & DOS R/O        \\
8 & AIX                 & 82 & Swap Linux    & f2 & DOS secondaire  \\
9 & AIX bootable        & 83 & Linux natif & ff & BBT            \\
a & Boot manag OS/2      & 93 & Amoeba       &    &                \\
\hline
\end{tabular}
\end{center}
\caption{Types de partitions (à partir du programme \cmd{fdisk} de Linux).}
\label{tab:partition-ids}
\end{table}

\subsection{Partitionner un disque dur}

	Il existe beaucoup de programmes pour créer et supprimer des partitions. La plupart des systèmes
d'exploitations ont les leurs, et il est préférable d'utiliser le programme propre à chaque système, juste
pour le cas où il ferait quelque chose d'inhabituel que les autres ne peuvent faire. La plupart de ces
programmes, y compris celui de Linux, s'appellent \cmd{fdisk}, ou quelque chose comme ça. Des détails
sur l'utilisation du programme \cmd{fdisk} de Linux sont donnés dans sa page du manuel en ligne. La commande
\cmd{cfdisk} est similaire à \cmd{fdisk}, mais possède une interface utilisateur plus agréable (plein écran).

	Lorsqu'on utilise des disques IDE, la partition de boot (celle qui contient les fichiers images du noyau) doit 
se trouver entièrement dans les 1024 premiers cylindres. Cela est d\^u au fait que le disque est utilisé via
le BIOS lors du boot (avant que le système ne passe en mode protégé), et le BIOS ne peut gérer
plus de 1024 cylindres. Il est parfois possible d'utiliser une partition de boot qui est seulement en
partie dans les 1024 premiers cylindres. Ceci fonctionne tant que tous les fichiers qui sont lus par le BIOS se
trouvent dans les 1024 premiers cylindres. Comme c'est difficile à arranger, c'est une \emph{très mauvaise idée}
de faire comme ça ; on ne sait jamais quand une mise à jour du noyau, ou une défragmentation rendra le
système indémarrable. Par conséquent, assurez-vous que votre partition de boot tienne complètement dans
les 1024 premiers cylindres.

	Quelques versions plus récentes du BIOS et de disques IDE peuvent, en fait, gérer des disques ayant plus de 1024
cylindres. Si vous \^etes s\^urs d'avoir un tel matériel, oubliez ce problème ; sinon mettez la partition de boot dans
les 1024 premiers cylindres.

	Chaque partition doit avoir un nombre pair de secteurs car les systèmes de fichiers de Linux utilisent une taille
de bloc de 1~Ko, i.e., deux secteurs.  Un nombre impair de secteur ferait que le dernier ne serait pas utilisé. Cela ne
poserait pas de problème, mais ce n'est pas beau, et certaines versions de \cmd{fdisk} avertissent de cette situation.

	Changer la taille d'une partition nécessite de sauvegarder d'abord tout ce que l'on veut sauver de cette partition
(il est préférable de sauvegarder le disque tout entier, juste au cas où...), détruire la partition, créer la nouvelle puis
restaurer tout sur celle-ci. Si la partition a grandi, on peut \^etre amené à ajuster (et donc à sauvegarder et restaurer) les
tailles des partitions adjacentes.

	Le changement de taille des partitions étant douloureux, il est préférable de bien partitionner dès le début, ou
d'avoir une politique de sauvegarde et de restauration efficace et facile à mettre en \oe uvre. 
Si l'on installe à partir d'un support ne nécessitant pas trop d'intervention humaine (par exemple, à partir d'un CD-ROM, au
contraire des disquettes), il est souvent facile d'essayer d'abord plusieurs configurations. Comme l'on n'a pas encore trop de
données à sauvegarder, la modification fréquente des tailles des partitions est moins pénible.

	\cmd{fips} est un programme pour MS-DOS qui modifie la taille d'une partition MS-DOS existante sans nécessiter de
sauvegardes ni de restauration. Mais, pour les autres systèmes de fichiers, cela reste nécessaire.

\subsection{Fichiers pilotes de périphériques et partitions}

	Toute partition et  partition étendue possède son propre fichier pilote. Les conven\-tions de noms de ces fichiers font
que le numéro de la partition est ajouté à la suite du nom du disque, avec la règle suivante~: 1--4 sont les partitions
primaires (quel que soit le nombre de partitions primaires), et 5--8 sont les partitions logiques (que que soit la
partition primaire dans laquelle elles se trouvent). Par exemple, \fn{/dev/hda1} est la première partition primaire du
premier disque IDE, et \fn{/dev/sdb7} est la troisième partition étendue du deuxième disque SCSI. La liste des périphériques,
dans~\cite{device-list} donne plus d'informations.

\section{Systèmes de fichiers}
\label{sec:filesystems}

\subsection{Qu'est-ce qu'un système de fichiers ?}

	Un \defin{système de fichiers} regroupe les méthodes et les structures de données qu'un système d'exploitation
utilise pour gérer les fichiers sur un disque ou une partition. C'est donc la façon dont sont organisés les fichiers sur
le disque. Le mot est aussi utilisé pour désigner la partition ou le disque utilisés pour stocker les fichiers, ou le
type du système de fichiers. Ainsi, on peut dire << j'ai deux systèmes de fichiers >> pour signifier que l'on a deux
partitions sur lesquelles on stocke les fichiers, ou dire que l'on utilise le << système de fichiers étendu >> pour signifier
le type du système de fichiers.

        La différence entre un disque ou une partition et le système de fichiers qu'il (qu'elle) contient est importante.
Quelques programmes (notamment ceux, et c'est normal, qui créent les systèmes de fichiers) opèrent directement sur
les secteurs bruts d'un disque ou d'une partition : s'il y avait déjà un système de fichiers, il serait alors détruit ou
sérieusement ab\^\i mé. La plupart des programmes travaillent avec un système de fichiers et ne fonctionneront donc pas
sur une partition qui n'en n'a pas (ou qui en a un du mauvais type).

	Avant qu'une partition ou un disque ne soit utilisé(e) comme système de fichiers, elle (il) a besoin d'\^etre initialisé(e) et les structures de données nécessaires doivent \^etre écrites sur le disque. Ce processus s'appelle
la \defin{création d'un système de fichiers}.

	La plupart des systèmes de fichiers UNIX ont des structures générales similaires, bien que les détails exacts
varient quand m\^eme un peu. Les concepts centraux sont ceux de \defin{super-bloc}, \defin{inode}, \defin{bloc de
données}, \defin{bloc de répertoire}, et \defin{bloc d'indirection}. Le super-bloc contient les informations sur
l'ensemble du système de fichiers, comme sa taille (cette information dépend du système de fichiers). Un inode contient
toutes les informations concernant un fichier, sauf son nom. Le nom est stocké dans le répertoire avec le numéro
d'inode. Une entrée de répertoire est composée d'un nom de fichier et du numéro d'inode qui représente le fichier. 
L'inode contient les numéros de plusieurs blocs de données, ceux qui sont utilisés pour stocker les données du
fichier. Il y a seulement la place pour quelques numéros de blocs de données dans l'inode, cependant, s'il en faut
plus, de l'espace supplémentaire pour des pointeurs vers les blocs de données est alloué dynamiquement. Ces blocs
de données alloués dynamiquement sont des blocs indirects ; ce nom implique que, pour trouver le bloc de données, 
on doit d'abord  trouver son numéro dans le bloc d'indirection.

%	\meta this needs rewriting.  
	Les systèmes de fichiers UNIX permettent généralement de créer un \defin{trou} dans un fichier (ce qui est
fait avec \cmd{lseek} ; voir la page du manuel), ce qui signifie que le système de fichier prétend seulement, qu'à un certain
endroit du fichier, il y a 0 octets mais qu'aucun secteur du disque n'est réservé pour cet endroit du fichier (cela
veut dire que le fichier utilisera moins d'espace disque). Ceci arrive en particulier pour les petites
bibliothèques, les bibliothèques partagées Linux, quelques bases de données, et quelques autres cas spéciaux. (Les
trous sont implantés en stockant une valeur spéciale pour l'adresse du bloc de données dans le bloc indirect ou dans
l'inode. Cette adresse spéciale signifie qu'aucun bloc de données n'est alloué pour cette partie du fichier, c'est
donc un trou dans le fichier).

	Les trous sont modérément utiles. Sur le système de l'auteur, une simple mesure montre un potentiel de
4 Mo économisés gr\^ace aux trous sur à peu près 200 Mo d'espace disque utilisé. Ce système, cependant, 
contient relativement peu de pro\-gram\-mes et aucun fichier de base de données. L'outil de mesure est décrit
dans l'annexe.

\subsection{Des systèmes de fichiers à gogo}

	Linux supporte plusieurs types de systèmes de fichiers. Au moment où nous rédigeons, les plus
importants sont~:
		%
	\begin{dispitems}
	\item[minix]
		Le plus ancien, présumé le plus fiable, mais plut\^ot limité dans ses caractéristiques
(certains marquage de dates manquent, noms de fichiers limités à 30 caractères) et restreint dans ses 
capacités (au plus 64~Mo par système de fichiers).
	\item[xia]
		Une version modifiée du système de fichiers minix qui repousse les limites sur les noms de
fichiers et les tailles du système de fichiers, mais n'introduit pas d'autres caractéristiques. Il n'est
pas très répandu mais fonctionne très bien.
	\item[ext2]
		Le plus riche des systèmes de fichiers natifs Linux, c'est aussi le plus répandu. Il est
conçu pour avoir une compatibilité ascendante aisée, de telle façon que des nouvelles versions du code
de ce système de fichiers ne nécessiteront pas la re-création des systèmes de fichiers existants. 
	\item[ext]
		Une ancienne version de \texttt{ext2} qui n'avait pas de compatibilité ascendante. Elle
n'est quasiment plus utilisée dans les nouvelles installations et la plupart des gens ont migré vers
\texttt{ext2}.
	\end{dispitems}
		%
	De plus, plusieurs systèmes de fichiers étrangers sont supportés afin de faciliter l'échange de
fichiers avec d'autres systèmes d'exploitation. Les systèmes de fichiers étrangers fonctionnent exactement comme
les systèmes natifs, sauf qu'ils peuvent ne pas disposer de certaines caractéristiques usuelles d'UNIX, ou avoir
des limitations curieuses ou autres bizarreries.
		%
	\begin{dispitems}
	\item[msdos]
		Compatibilité avec les systèmes de fichiers FAT de MS-DOS (d'OS/2 et de Windows NT)
	\item[umsdos]
		\'Etend le pilote du système de fichiers \texttt{msdos} sous Linux afin de disposer
des noms longs de fichiers, du concept d'appartenance, de permissions, de liens et de fichiers pilotes. Ceci permet
à un système de fichier \texttt{msdos} normal d'\^etre utilisé comme s'il s'agissait d'un système de
fichiers Linux, supprimant ainsi la nécessité d'avoir une partition séparée pour Linux.
	\item[iso9660]
		Le système de fichiers standard pour les CD-ROMs ; l'extension Rock Ridge du standard, qui permet
d'utiliser des noms de fichiers plus longs est supportée automatiquement.
	\item[nfs]
		Système de fichiers permettant le partage des données entre plusieurs ordinateurs en réseau. Cela
facilite ainsi l'accès aux fichiers de chacun d'entre eux.
	\item[hpfs]
		Le système de fichiers d'OS/2.
	\item[sysv]
		Le système de fichiers de SystemV/386, Coherent, et Xenix.
	\end{dispitems}
		%
	Le choix d'un système de fichiers dépend de la situation. Si la compatibilité ou d'autres raisons nécessitent
l'utilisation d'un des systèmes de fichiers non natifs, alors on doit l'utiliser. Si l'on peut choisir librement, il
est sûrement préférable d'utiliser \texttt{ext2} puisqu'il possède toutes les caractéristiques sans souffrir d'une perte de
performances.

	Il y a aussi le système de fichiers \texttt{proc}, généralement accessible en tant que
répertoire \fn{/proc}, et qui n'est pas réellement un système de fichiers m\^eme s'il se présente comme tel. Le
système de fichiers \texttt{proc} facilite l'accès à certaines structures de données du noyau, comme la
liste des processus (d'où son nom). Il fait ressembler ces structures de données à un système de fichiers qui peut
\^etre manipulé avec tous les outils habituels sur les fichiers. Par exemple, pour obtenir une liste de tous les
processus, on peut utiliser la commande~:
		%
		\begin{tscreen}
\verb|$ | {\sl ls -l /proc} \\
\verb|total 0| \\
\verb|dr-xr-xr-x   4 root     root            0 Jan 31 20:37 1| \\
\verb|dr-xr-xr-x   4 liw      users           0 Jan 31 20:37 63| \\
\verb|dr-xr-xr-x   4 liw      users           0 Jan 31 20:37 94| \\
\verb|dr-xr-xr-x   4 liw      users           0 Jan 31 20:37 95| \\
\verb|dr-xr-xr-x   4 root     users           0 Jan 31 20:37 98| \\
\verb|dr-xr-xr-x   4 liw      users           0 Jan 31 20:37 99| \\
\verb|-r--r--r--   1 root     root            0 Jan 31 20:37 devices| \\
\verb|-r--r--r--   1 root     root            0 Jan 31 20:37 dma| \\
\verb|-r--r--r--   1 root     root            0 Jan 31 20:37 filesystems| \\
\verb|-r--r--r--   1 root     root            0 Jan 31 20:37 interrupts| \\
\verb|-r--------   1 root     root      8654848 Jan 31 20:37 kcore| \\
\verb|-r--r--r--   1 root     root            0 Jan 31 11:50 kmsg| \\
\verb|-r--r--r--   1 root     root            0 Jan 31 20:37 ksyms| \\
\verb|-r--r--r--   1 root     root            0 Jan 31 11:51 loadavg| \\
\verb|-r--r--r--   1 root     root            0 Jan 31 20:37 meminfo| \\
\verb|-r--r--r--   1 root     root            0 Jan 31 20:37 modules| \\
\verb|dr-xr-xr-x   2 root     root            0 Jan 31 20:37 net| \\
\verb|dr-xr-xr-x   4 root     root            0 Jan 31 20:37 self| \\
\verb|-r--r--r--   1 root     root            0 Jan 31 20:37 stat| \\
\verb|-r--r--r--   1 root     root            0 Jan 31 20:37 uptime| \\
\verb|-r--r--r--   1 root     root            0 Jan 31 20:37 version| \\
\verb|$ |
		\end{tscreen}
		%
	(En vérité, il y aurait d'autres fichiers qui ne correspondent pas à des processus. L'exemple ci-dessus a été
raccourci.)

	On notera que, bien qu'il soit appelé système de fichiers, aucune partie de \texttt{proc} ne
touche à un disque. Il existe simplement dans l'imagination du noyau. A chaque fois que quelqu'un essaie de
regarder une partie du système de fichiers \texttt{proc}, le noyau la montre comme si elle existait quelque part.
En conséquence, m\^eme si il y a un fichier \fn{/proc/kcore} de plusieurs méga-octets, il ne prend aucune place sur
le disque.

\subsection{Quel système de fichiers utiliser ?}

	Il y a généralement peu de raisons d'utiliser plusieurs systèmes de fichiers différents. Actuellement, 
\texttt{ext2fs} est le
plus répandu, et probablement le meilleur choix. Selon le surco\^ut d\^u aux structures de données, la vitesse,
la fiabilité (perçue), la compatibilité, et pour diverses autres raisons, il peut \^etre préférable d'utiliser un
autre système de fichiers. Ceci doit \^etre décidé au cas par cas.

\subsection{Création d'un système de fichiers}\label{sec:mkfs}

	Les systèmes de fichiers sont créés, i.e. initialisés avec la commande \cmd{mkfs}. En fait, il y a un programme distinct
pour chaque type de système de fichiers. \cmd{mkfs} est juste un frontal qui lance le programme approprié selon le
type voulu. Le type est sélectionné en utilisant l'option \texttt{-t fstype}.

	Les programmes appelés par \cmd{mkfs} ont des interfaces de commandes légèrement différentes. Les options les
plus fréquentes et les plus importantes sont résumées ci-dessous ; voir les pages du manuel pour les autres.
	%
	\begin{quote}
	\begin{description}
	\item[{\tt -t} {\it fstype}] Sélectionne le type de système de fichiers.
	\item[{\tt -c}] Recherche les blocs défectueux et initialise en conséquence la liste des mauvais blocs.
	\item[{\tt -l} {\it nomfic}] Lit la liste des mauvais blocs à partir du fichier	{\it nomfic}.
	\end{description}
	\end{quote}
	%
	Pour créer un système de fichier ext2 sur une disquette, on taperait les commandes suivantes~:
		%
		\begin{tscreen}
\verb|$| {\sl fdformat -n /dev/fd0H1440 } \\
\verb|Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB.| \\
\verb|Formating ... done| \\
\verb|$| {\sl badblocks /dev/fd0H1440 1440 $>$ bad-blocks} \\
\verb|$| {\sl mkfs -t ext2 -l bad-blocks /dev/fd0H1440} \\
\verb|mke2fs 0.5a, 5-Apr-94 for EXT2 FS 0.5, 94/03/10| \\
\verb|360 inodes, 1440 blocks| \\
\verb|72 blocks (5.00%) reserved for the super user| \\
\verb|First data block=1| \\
\verb|Block size=1024 (log=0)| \\
\verb|Fragment size=1024 (log=0)| \\
\verb|1 block group| \\
\verb|8192 blocks per group, 8192 fragments per group| \\
\verb|360 inodes per group| \\
\verb||\\
\verb|Writing inode tables: done     | \\
\verb|Writing superblocks and filesystem accounting information: done| \\
\verb|$|
		\end{tscreen}
		%
	La disquette est d'abord formatée (l'option \texttt{-n} évite la vérification des blocs
défectueux). Puis, les mauvais blocs sont recherchés gr\^ace à \cmd{badblocks} dont la sortie est redirigée vers un
fichier~: \texttt{bad-blocks}.  Enfin, le système de fichiers est créé en utilisant la liste des mauvais blocs
initialisée avec tous ceux que \cmd{badblocks} a trouvés.

	L'option {\tt -c} aurait pu \^etre utilisée avec \cmd{mkfs} à la place de \cmd{badblocks} et d'un fichier séparé. 
L'exemple ci-dessous fait cela~:
		%
		\begin{tscreen}
\verb|$| {\sl mkfs -t ext2 -c /dev/fd0H1440} \\
\verb|mke2fs 0.5a, 5-Apr-94 for EXT2 FS 0.5, 94/03/10| \\
\verb|360 inodes, 1440 blocks| \\
\verb|72 blocks (5.00%) reserved for the super user| \\
\verb|First data block=1| \\
\verb|Block size=1024 (log=0)| \\
\verb|Fragment size=1024 (log=0)| \\
\verb|1 block group| \\
\verb|8192 blocks per group, 8192 fragments per group| \\
\verb|360 inodes per group| \\
\verb| | \\
\verb|Checking for bad blocks (read-only test): done| \\
\verb|Writing inode tables: done     | \\
\verb|Writing superblocks and filesystem accounting information: done| \\
\verb|$ |
		\end{tscreen}
		%
	L'option {\tt -c} est plus pratique qu'une utilisation séparée de
	\cmd{badblocks}, mais \cmd{badblocks} est nécessaire aux vérifications après que le système de
fichiers ait été créé.
	
	La préparation des systèmes de fichiers pour les disques durs ou les partitions est la m\^eme que
pour les disquettes, sauf que le formatage n'est pas nécessaire.

\subsection{Montage et démontage}\label{subsec:mount}

	Avant que l'on puisse utiliser un système de fichiers, celui-ci doit \^etre \defin{monté}. Le système
d'exploitation réalise alors diverses t\^aches de vérification afin de s'assurer que tout fonctionne correctement.
Comme tous les fichiers d'UNIX sont dans une seule arborescence, l'opération de montage fera appara\^\i tre 
 le contenu du  nouveau système de fichiers comme s'il s'agissait d'un sous-répertoire existant dans un système de
fichiers déjà monté.

	Par exemple, la figure~\ref{fig:hd-mount-root} montre trois systèmes de fichiers distincts, chacun
ayant son propre répertoire racine. Quand les deux derniers sont montés sous \fn{home} et \fn{/usr} du premier système de
fichiers, on obtient une seule arborescence, celle de la figure~\ref{fig:hd-mount-all}.

		\begin{figure}[thb]
		\begin{center}
		\input{disks/hd-mount-separate.tex}
		\end{center}
		\caption{Trois systèmes de fichiers séparés.}
		\label{fig:hd-mount-root}
		\end{figure}

		\begin{figure}[thb]
		\begin{center}
		\input{disks/hd-mount-mounted.tex}
		\end{center}
		\caption{\fn{/home} et \fn{/usr} ont été montés.}
		\label{fig:hd-mount-all}
		\end{figure}

	Les montages ont été faits en utilisant les commandes suivantes~:
		%
		\begin{tscreen}
\verb|$ | {\sl mount /dev/hda2 /home} \\
\verb|$ | {\sl mount /dev/hda3 /usr} \\
\verb|$ |
		\end{tscreen}
		%
	La commande \cmd{mount} prend deux arguments. Le premier est le fichier spécial cor\-res\-pon\-dant au disque ou à la partition
contenant le système de fichiers. Le second est le répertoire sous lequel il sera monté. Après ces deux commandes, les contenus
des deux systèmes de fichiers apparaissent comme les contenus respectifs des répertoires \fn{/home} et \fn{/usr}. On dit alors
que << \fn{/dev/hda2} \defin{est monté sur}  \fn{/home} >>, de m\^eme pour \fn{/usr}. Pour consulter l'un des systèmes de
fichiers, on consulte le contenu du répertoire sur lequel il a été monté, simplement comme pour tout autre répertoire. On 
notera la différence entre le fichier spécial \fn{/dev/hda2}, et le répertoire de montage \fn{/home}. Le fichier spécial donne
accès au contenu brut du disque, tandis que le répertoire de montage donne accès aux fichiers du disque. Le répertoire de
montage est appelé \defin{point de montage}.

	Linux supporte plusieurs types de systèmes de fichiers. \cmd{mount} essaie de deviner le type du système de
fichiers. On peut aussi utiliser l'option {\tt -t \sl fstype} pour spécifier directement le type ; c'est quelques fois 
nécessaire car les heuristiques que \cmd{mount} utilise ne fonctionnent pas toujours. Par exemple, pour monter une
disquette MS-DOS, on peut utiliser la commande suivante~:
		%
		\begin{tscreen}
\verb|$ | {\sl mount -t msdos /dev/fd0 /floppy} \\
\verb|$ |
		\end{tscreen}
		%
	Le répertoire de montage n'a pas besoin d'\^etre vide, mais il doit exister. Cependant, tous les fichiers
qu'il contient seront inaccessibles par leurs noms tant que le système de fichiers est monté. (Tout fichier déjà ouvert sera
encore accessible. Les fichiers ayant des liens à partir d'autres répertoires pourront \^etre accédés en utilisant ces noms.)
Cela n'est pas grave, et peut m\^eme s'avérer utile. Par exemple, certains préfèrent avoir \fn{/tmp} et \fn{/var/tmp} en tant que
synonymes et font de \fn{/tmp} un lien symbolique vers \fn{/var/tmp}. Quand le système est lancé, avant que le système de
fichiers \fn{/var} ne soit monté, un répertoire \fn{/var/tmp} résident sur le système de fichiers racine est utilisé à la place.
Quand \fn{/var} est monté, il rend le répertoire \fn{/var/tmp} inaccessible. Si \fn{/var/tmp} n'existait pas sur le système
de fichiers racine, il serait impossible d'utiliser des fichiers temporaires avant de monter \fn{/var}.

	Si l'on n'a pas l'intention d'écrire quoi que ce soit sur le système de fichiers, on utilise l'option
	{\tt -r} de \cmd{mount} pour avoir un \defin{montage en lecture seule}. 
Cela fait que le noyau bloquera toute
tentative d'écriture sur le système de fichiers et emp\^echera aussi la mise à jour des dates d'accès aux fichiers
dans les inodes. Les montages en lecture seulement sont nécessaires pour les supports sur lesquels on ne peut écrire,
 par
exemple~: les CD-ROMs.

	Le lecteur attentif aura déjà remarqué un petit problème logistique. Comment est monté le premier
système de fichiers (appelé système de fichiers \defin{racine}, car il contient le répertoire racine), puisqu'il
est évident qu'il ne peut \^etre monté sur un autre système de fichiers ? Et bien, la réponse est que cela
est réalisé par magie\footnote{Pour plus d'informations, voir les sources du noyau ou le Kernel Hackers' Guide.}.
Le système de fichiers racine est monté au moment du démarrage, et on peut considérer qu'il est toujours
monté --~si le système de fichiers racine ne peut \^etre monté, Linux ne peut démarrer. Le nom du système
de fichiers qui est monté en tant que racine est soit compilé dans le noyau, soit établi en utilisant
LILO ou \cmd{rdev}.

	Le système de fichiers racine est, d'habitude, d'abord monté en lecture seule. Les scripts de
démarrage lancent ensuite \cmd{fsck} pour vérifier sa validité et l'absence de problèmes, puis ils
le \defin{re-montent} pour autoriser aussi les écritures. \cmd{fsck} ne doit pas \^etre lancé sur un système de
fichiers monté, car tout changement dans le système de fichiers pendant que \cmd{fsck} s'exécute \emph{causerait}
des problèmes. Le système de fichiers racine étant monté en lecture seule pendant qu'il est vérifié, 
\cmd{fsck} peut réparer tout problème sans souci car l'opération de re-montage videra toute donnée que le système
gardait en mémoire.

	Sur beaucoup d'installations, il y a d'autres systèmes de fichiers qui peuvent aussi \^etre montés au 
démarrage. Ils sont spécifiés dans le fichier \fn{/etc/fstab} ; voir la page \man{fstab} du manuel en ligne
pour les détails concernant son format. Le moment où les systèmes de fichiers 
supplémentaires sont montés dépend de plusieurs facteurs, et peut \^etre configuré par l'administrateur
si besoin est. Lorsque le chapitre sur le démarrage sera terminé, vous pourrez lire tout ce qu'il faut pour cela.

	Lorsqu'un système de fichiers n'a plus besoin d'\^etre monté, il peut \^etre démonté avec
	\cmd{umount}\footnote{Cela devrait \^etre
	\cmd{unmount}, mais le {\tt n} a mystérieusement disparu dans les années 70, et n'a plus été revu depuis.
Retournez-le aux Bell Labs, NJ, si vous le trouvez.}. \cmd{umount} prend un seul argument~: soit le fichier
spécial, soit le point de montage. Par exemple, pour démonter les répertoires de l'exemple précédent, on peut
utiliser les commandes suivantes~:
		%
		\begin{tscreen}
\verb|$ | {\sl umount /dev/hda2 } \\
\verb|$ | {\sl umount /usr} \\
\verb|$ |
		\end{tscreen}
		%
	Voir les pages du manuel pour de plus amples informations sur l'utilisation de cette commande.
Il est impératif de toujours démonter une disquette montée. \emph{N'\^otez jamais la disquette du 
lecteur avant de l'avoir démontée !} A cause du cachage des disques, les données ne sont pas nécessairement
écrites sur la disquette tant que l'on ne l'a pas démontée, enlever la disquette du lecteur trop t\^ot peut faire
que les contenus soient altérés. Si l'on n'a fait que lire la disquette, ce n'est pas trop grave, mais si l'on
a écrit dessus, m\^eme accidentellement, le résultat peut \^etre catastrophique.
	
Le montage et le démontage requièrent les privilèges du super-utilisateur, donc seul \fn{root} peut le faire. La raison est que,
si tout utilisateur pouvait monter une disquette sur n'importe quel répertoire, il serait alors facile de créer une disquette avec, par exemple, un cheval de Troie déguisé en 
	\cmd{/bin/sh}, ou tout autre programme couramment utilisé. Cependant, il est souvent nécessaire de permettre aux
utilisateurs d'utiliser les disquettes, et il y a plusieurs façons de procéder~:
		%
	\begin{itemize}
	\item Donner aux utilisateurs le mot de passe \fn{root}. C'est évidemment une mauvaise mesure de sécurité mais c'est la
solution la plus facile. Cela fonctionne bien si la sécurité n'est jamais nécessaire, ce qui est le cas sur de nombreux
systèmes personnels non reliés à un réseau.
	\item Utiliser un programme comme \cmd{sudo} pour autoriser le montage aux utilisateurs. C'est encore une mauvaise
mesure de sécurité, mais elle ne donne pas directement les privilèges du super-utilisateur à tout le monde\footnote{Cela
nécessite plusieurs secondes de réflexion à propos de l'intér\^et de l'utilisateur.}.
	\item Permettre aux utilisateurs d'utiliser \cmd{mtools}, un paquetage pour la manipulation des systèmes
de fichiers MS-DOS qui ne nécessite pas de montage. Cela fonctionne bien si seules des disquettes MS-DOS sont utilisées,
dans les autres cas, c'est plut\^ot peu commode.
	\item Lister les pilotes de disquettes et leurs points de montages avec les options convenables dans le fichier	\fn{/etc/fstab}.
	\end{itemize}
		%
	Cette dernière possibilité peut \^etre réalisée en ajoutant une ligne comme celle qui suit dans le fichier 
	\fn{/etc/fstab}~:
		%
		\begin{tscreen}
/dev/fd0            /floppy      msdos   user,noauto      0     0
		\end{tscreen}
		%
	Les différentes colonnes correspondent au fichier pilote à monter, au répertoire de montage, au type de système de
fichiers, aux options, à la fréquence de sauvegarde (utilisée par \cmd{dump}), et au numéro de passage de \cmd{fsck} (pour spécifier
l'ordre dans lequel les systèmes de fichiers doivent \^etre vérifiés au moment du démarrage ; 0 signifie qu'il n'y aura
pas de vérification).

	L'option \texttt{noauto} emp\^eche le montage d'\^etre réalisé automatiquement au démarrage du système (il 
emp\^eche \cmd{mount -a} de la monter). L'option \texttt{user} autorise tous les utilisateurs à monter le système de
fichiers, et, pour des raisons de sécurité, interdit l'exécution des programmes (normaux ou setuid) et l'interprétation des
fichiers pilotes se trouvant sur ce système de fichiers. Après cela, tout utilisateur peut monter une disquette ayant
un système de fichiers \texttt{msdos} avec la commande suivante~:
		%
		\begin{tscreen}
\verb|$ | {\sl mount /floppy} \\
\verb|$ |
		\end{tscreen}
		%
	La disquette peut (et doit, bien s\^ur) \^etre démontée avec la commande \cmd{umount} cor\-res\-pon\-dan\-te.

	Si l'on veut permettre l' accès à différents types de disquettes, on doit donner plusieurs points de montage. Les
réglages peuvent \^etre différents pour chaque point de montage. Par exemple, pour permettre l'accès à la fois aux disquettes
MS-DOS et ext2, on pourrait avoir les lignes suivantes dans \fn{/etc/fstab}~:
		%
		\begin{quote}
		\small
		\begin{verbatim}
/dev/fd0    /dosfloppy    msdos   user,noauto  0  0
/dev/fd0    /ext2floppy   ext2    user,noauto  0  0
		\end{verbatim}
		\end{quote}
		%
	En ce qui concerne les systèmes de fichiers MS-DOS (pas seulement les disquettes), on voudra probablement en restreindre
l'accès en utilisant les options \texttt{uid}, \texttt{gid}, et \cmd{umask}, décrites en détail dans la page \man{mount} du manuel en ligne. Si l'on est imprudent, monter un système de fichiers MS-DOS donne à tout le monde au moins le droit de lire les
fichiers qui s'y trouvent, ce qui n'est pas une bonne idée.
	
\subsection{Vérification de l'intégrité d'un système de fichiers avec \cmd{fsck}}

Les systèmes de fichiers sont des créatures complexes, et, comme telles, elles ont tendance à \^etre sujets aux erreurs. La
cohérence et la validité d'un système de fichiers peuvent \^etre vérifiées gr\^ace à la commande \cmd{fsck}. Celle-ci
peut \^etre configurée pour réparer toutes les erreurs mineures qu'elle rencontre, et pour avertir l'utilisateur des
problèmes non réparables. Heureusement, le code implantant les systèmes de fichiers est plut\^ot bien débuggé, il y a donc
rarement des problèmes et, lorsqu'il y en a,  ils sont le plus souvent causés par des coupures de courant, du matériel défectueux ou des erreurs de
manipulation ; par exemple, en n'éteignant pas correctement le système.

	La plupart des systèmes sont configurés pour lancer automatiquement \cmd{fsck} au moment du démarrage, de façon à 
détecter (et avec de la chance, corriger) toutes les erreurs avant que le système ne soit utilisé. L'utilisation d'un système de
fichiers corrompu empire les choses~: si les structures de données sont en désordre, l'utilisation du système de fichiers
augmentera probablement ce désordre ce qui aura pour résultat une perte plus importante de données. Cela dit, 
	\cmd{fsck} peut mettre du temps à s'exécuter sur  les gros systèmes de fichiers, et, comme les erreurs n'arrivent
presque jamais lorsqu'un système est éteint correctement, plusieurs ruses sont employées pour éviter les vérifications dans de
tels cas. La première est que, si le fichier \fn{/etc/fastboot} existe, aucune vérification n'est faite. La seconde est que
le système de fichiers ext2 a un marqueur spécial dans son super-bloc qui indique si le système de fichiers a été démonté
proprement à la suite du montage précédent. Ceci permet à \cmd{e2fsck} (la version de \cmd{fsck} pour ext2)
d'éviter la vérification du système de fichiers si le marqueur indique que le démontage a été fait (l'hypothèse étant qu'un
démontage propre indique qu'il n'y a pas de problème). Le fonctionnement de l'astuce \fn{/etc/fastboot} dépend des scripts de
démarrage du système, mais l'astuce ext2 fonctionne à chaque fois que l'on utilise \cmd{e2fsck}~--~ elle doit \^etre
explicitement court-circuitée au moyen d'une option pour emp\^echer \cmd{e2fsck}. (Voir la page du manuel concernant
\man{e2fsck} pour de plus amples explications).

La vérification automatique fonctionne uniquement avec les systèmes de fichiers qui sont automatiquement montés au
démarrage. On utilise \cmd{fsck} manuellement pour vérifier les autres systèmes de fichiers, par exemple les disquettes.

	Si \cmd{fsck} détecte des problèmes non réparables; on doit posséder une bonne connais\-sance du fonctionnement
des systèmes de fichiers en général et du système corrompu en particulier, ou alors avoir de bonnes sauvegardes. Cette dernière solution est facile à mettre en place (quoique parfois fastidieuse), la première solution peut parfois s'arranger avec
l'aide d'un ami, des groupes de news et des listes de diffusion Linux, lorsqu'on ne possède pas soi-m\^eme les 
connaissances requises. J'aimerais vous en dire plus là-dessus, mais mon manque d'expérience sur ce sujet m'en emp\^eche.
Le programme \cmd{debugfs} de Theodore T'so devrait \^etre utile.
	
\cmd{fsck} doit \^etre lancé uniquement sur des systèmes de fichiers non montés (exception faite du système root en 
lecture seulement au moment du démarrage). Ceci parce que ce programme accède au disque << brut >>, et peut donc 
modifier le système de fichiers sans que le système d'exploitation ne s'en rende compte. Ce serait problématique si le
système d'exploitation était trompé.

\subsection{Vérifier les erreurs disque avec \cmd{badblocks}}

C'est une bonne idée de vérifier périodiquement les blocs défectueux. Ceci est réalisé gr\^ace à la commande
\cmd{badblocks}. Elle produit une liste des numéros de tous les blocs défectueux qu'elle trouve. Cette liste peut 
\^etre envoyée à \cmd{fcsk} pour \^etre enregistrée dans les structures de données du système de fichiers de façon à 
ce que le système d'exploitation n'essaie pas d'utiliser les mauvais blocs pour stocker des données. L'exemple
suivant montre une utilisation possible~:
		%
		\begin{tscreen}
\verb|$| {\sl badblocks /dev/fd0H1440 1440 $>$ bad-blocks } \\
\verb|$| {\sl fsck -t ext2 -l bad-blocks /dev/fd0H1440} \\
\verb|Parallelizing fsck version 0.5a (5-Apr-94)| \\
\verb|e2fsck 0.5a, 5-Apr-94 for EXT2 FS 0.5, 94/03/10| \\
\verb|Pass 1: Checking inodes, blocks, and sizes| \\
\verb|Pass 2: Checking directory structure| \\
\verb|Pass 3: Checking directory connectivity| \\
\verb|Pass 4: Check reference counts.| \\
\verb|Pass 5: Checking group summary information.| \\
\verb| | \\
\verb|/dev/fd0H1440: ***** FILE SYSTEM WAS MODIFIED *****| \\
\verb|/dev/fd0H1440: 11/360 files, 63/1440 blocks| \\
\verb|$ |
		\end{tscreen}
		%
Si badblocks trouve un bloc déjà utilisé, \cmd{e2fsck} essaie de déplacer celui-ci à un autre emplacement. Si le
bloc est vraiment ab\^\i mé, le contenu du fichier peut \^etre corrompu.

\subsection{Lutter contre la fragmentation}

Quand un fichier est écrit sur disque, il ne peut pas toujours l'\^etre dans des blocs consécutifs. Un fichier qui n'est
pas stocké dans des blocs consécutifs est \defin{fragmenté}. Cela prend plus de temps pour lire un fichier fragmenté car
la t\^ete de lecture du disque doit se déplacer plus. Il est donc souhaitable d'éviter la fragmentation bien que ce soit
moins problématique avec un système pourvu d'un bon cache avec lecture anticipée.

Le système de fichiers ext2 tente de minimiser la fragmentation en mettant tous les blocs d'un fichier les uns près des
autres, m\^eme s'ils ne peuvent pas \^etre dans des secteurs consécutifs. Ext2 alloue toujours le bloc libre qui est le
plus près des autres blocs d'un fichier. Pour ext2, il est donc rarement nécessaire de se soucier de la fragmentation. Il
existe un programme pour défragmenter un système de fichiers ext2, voir~\cite{ext2-defrag} dans la bibliographie.

Il existe de nombreux programmes de défragmentation MS-DOS qui déplacent les blocs du système de fichiers pour supprimer
la fragmentation. Pour  d'autres systèmes, la défragmentation doit \^etre réalisée en sauvegardant le système de
fichiers, en le recréant et en restaurant les fichiers à partir des sauvegardes. Sauvegarder un système de
fichiers avant de le défragmenter est une bonne idée dans tous les cas car plusieurs choses peuvent
mal tourner durant cette opération.

\subsection{Autres outils pour tous les systèmes de fichiers}

D'autres outils sont aussi utiles pour gérer les systèmes de fichiers.
	\cmd{df} montre l'espace disque libre sur un ou plusieurs systèmes de fichiers.
	\cmd{du} montre l'espace disque utilisé par un répertoire et tous les fichiers qu'il contient. Ces commandes
peuvent \^etre utilisées pour éviter le gaspillage de l'espace disque.

	\cmd{sync} force l'écriture sur disque de tous les blocs non-écrits se trouvant dans le tampon cache 
(voir la section~\ref{sec:buffer-cache}). Il est rarement nécessaire de le faire manuellement ; le processus démon
\cmd{update} le fait automatiquement. Ceci peut toutefois \^etre utile dans le cas de catastrophes, par exemple, si
\cmd{update} ou son processus associé
	\cmd{bdflush} meurt, ou si l'on veut éteindre le système \emph{tout de suite} et qu'on ne peut attendre l'exécution
de \cmd{update}.

\subsection{Autres outils pour le système de fichiers ext2}

En plus de la création du système de fichiers (\cmd{mke2fs}) et de sa vérification
(\cmd{e2fsck}) accessibles directement ou via des interfaces indépendantes du type de système de fichiers, le
système ext2 possède quelques outils supplémentaires qui peuvent s'avérer utiles.

	\cmd{tune2fs} ajuste les paramètres du système de fichiers. Quelques-uns des paramètres les plus 
intéressants sont~:
		%
	\begin{itemize}
	\item Un nombre maximal de montages. \cmd{e2fsck} force une vérification lorsque le système de
fichiers a été monté trop souvent, m\^eme si le marqueur indiquant que tout va bien est positionné. Pour un
système qui est utilisé pour développer ou tester le système, il peut \^etre préférable de réduire cette limite.
	\item Un délai maximal entre les vérifications.  \cmd{e2fsck} peut aussi forcer un délai maximal entre deux
vérifications, m\^eme si tout va bien, et que le système n'a pas été monté très souvent. Ceci peut cependant \^etre 
désactivé.
	\item Nombre de blocs réservés pour \texttt{root}.  Ext2
		réserve plusieurs blocs pour \texttt{root} de façon à ce que, si le système de fichiers est plein, il
soit encore possible de faire de l'administration système sans avoir à détruire quoi que ce soit. Par défaut, ce
nombre est de 5\%, ce qui, sur la plupart des disques n'implique pas une perte d'espace. Cependant, pour les
disquettes, il n'y a pas besoin de réserver le moindre bloc.
	\end{itemize}
		%
	Voir la page \man{tune2fs} du manuel pour plus d'information.

	\cmd{dumpe2fs} donne des informations sur un système de fichiers ext2, principalement à partir du
super-bloc. La figure~\ref{fig:dumpe2fs-output} montre une sortie de cette commande. Quelques informations de la
sortie sont techniques et requièrent la connaissance du fonction\-ne\-ment du système de fichiers 
(voir l'annexe~\ref{chap:ext2fspaper}), mais la plupart des informations sont aisément compréhensibles m\^eme
pour les administrateurs paresseux.

\begin{figure}[t]
\begin{center}
\small
\begin{verbatim}
dumpe2fs 0.5b, 11-Mar-95 for EXT2 FS 0.5a, 94/10/23
Filesystem magic number:  0xEF53
Filesystem state:         clean
Errors behavior:          Continue
Inode count:              360
Block count:              1440
Reserved block count:     72
Free blocks:              1133
Free inodes:              326
First block:              1
Block size:               1024
Fragment size:            1024
Blocks per group:         8192
Fragments per group:      8192
Inodes per group:         360
Last mount time:          Tue Aug  8 01:52:52 1995
Last write time:          Tue Aug  8 01:53:28 1995
Mount count:              3
Maximum mount count:      20
Last checked:             Tue Aug  8 01:06:31 1995
Check interval:           0
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)

Group 0:
  Block bitmap at 3, Inode bitmap at 4, Inode table at 5
  1133 free blocks, 326 free inodes, 2 directories
  Free blocks: 307-1439
  Free inodes: 35-360
\end{verbatim}
\end{center}
\caption{Sortie de la commande \cmd{dumpe2fs}}
\label{fig:dumpe2fs-output}
\end{figure}

\cmd{debugfs} est un débugger de système de fichiers. Il permet un accès direct aux structures de données stockées sur le
disque et peut ainsi \^etre utilisé pour réparer un disque qui est dans un état tel que \cmd{fsck} ne peut le
corriger automatiquement. Il peut aussi \^etre utilisé pour récupérer des fichiers détruits. Cependant,
\cmd{debugfs} nécessite que l'on sache parfaitement ce que l'on fait ; la moindre erreur peut détruire toutes les
données.

\cmd{dump} et \cmd{restore} peuvent \^etre utilisées pour sauvegarder un système de fichiers. Ce sont des versions spécifiques à ext2 des outils de sauvegarde UNIX traditionnels. Voir le chapitre~\ref{chap:backups} pour plus d'informations sur
les sauvegardes.

\section{Disques sans systèmes de fichiers}

	Tous les disques ou partitions ne sont pas utilisés comme systèmes de fichiers. Une partition de swap, par 
exemple, n'aura pas de système de fichiers. De nombreuses disquettes sont utilisées de façon à émuler un lecteur de
bande, ainsi un	\cmd{tar} ou un autre fichier est directement écrit sur le disque brut. Les disquettes de
démarrage Linux ne contiennent pas de système de fichiers mais uniquement le noyau pur.

	L'absence de système de fichiers a l'avantage de laisser plus d'espace utilisable sur le disque puisqu'un
système de fichiers nécessite toujours un surco\^ut d\^u à son organisation. Cela permet aussi aux disques d'\^etre
aisément compatibles avec les autres systèmes~: par exemple, le format de fichier \cmd{tar} est le m\^eme sur tous les
systèmes alors que les systèmes de fichiers sont différents sur la plupart des systèmes. On vient rapidement
aux disques sans systèmes de fichiers lorsqu'on en a besoin. Les disquettes bootables de Linux n'ont pas nécessairement
de système de fichiers, bien que cela soit aussi possible.

	Une raison d'utiliser des disques bruts et de faire des copies images de ceux-ci. Par exemple, si le disque 
contient un système de fichiers en partie ab\^\i mé, il est préférable d'en faire une copie exacte avant d'essayer de
le réparer car on peut alors recommencer si la réparation a empiré les choses. Une façon de faire est d'utiliser
\cmd{dd}~:
		%
		\begin{tscreen}
\verb|$| {\sl dd if=/dev/fd0H1440 of=floppy-image} \\
\verb|2880+0 records in| \\
\verb|2880+0 records out| \\
\verb|$| {\sl dd if=floppy-image of=/dev/fd0H1440 } \\
\verb|2880+0 records in| \\
\verb|2880+0 records out| \\
\verb|$|
		\end{tscreen}
		%
Le premier \cmd{dd} fait une image exacte de la disquette dans le fichier
	\fn{floppy-image}, le second écrit l'image sur la disquette. (On suppose que l'utilisateur
a échangé les disquettes avant la deuxième commande, sinon ces deux commandes sont peu utiles.)

\section{Allocation de l'espace disque}

\subsection{Procédés de partitionnement}

Partitionner un disque de la meilleure façon possible n'est pas chose aisée. De plus, il n'y a pas une méthode correcte
universelle pour ça, trop de facteurs sont en cause.

La méthode traditionnelle consiste à avoir un système de fichiers root (relativement) petit, qui contient
\fn{/bin}, \fn{/etc}, \fn{/dev}, \fn{/lib}, \fn{/tmp}, et tout ce qui est nécessaire au lancement et à l'exécution du
système. De cette façon, le système de fichiers root (dans sa propre partition ou son propre disque) suffit à 
mettre en place le système. Le raisonnement poursuivi est que si le système de fichiers root est petit et pas trop 
utilisé, il y a peu de chances qu'il soit ab\^\i mé lors d'un crash du système et qu'il sera donc plus facile
de corriger les problèmes provoqués par ce crash.  On crée donc des partitions distinctes ou on utilise des disques
différents pour l'arborescence des répertoires se trouvant sous \fn{/usr}, les répertoires utilisateurs
(souvent sous \fn{/home}), et l'espace de swap. Séparer les répertoires utilisateurs (avec les fichiers de ceux-ci) dans 
leur propre partition rend les sauvegardes plus faciles car il n'est généralement pas nécessaire de sauvegarder les
programmes (qui se trouvent sous \fn{/usr}). Dans un environnement en réseau, il est aussi possible de partager 
\fn{/usr} entre les différentes machines (par exemple, en utilisant NFS), et donc de réduire l'espace disque total requis
pour les dizaines ou centaines de méga-octets multipliés par le nombre de machines.

Le problème des partitions multiples est que cela divise l'espace disque disponible en plusieurs
petites parties. De nos jours, comme les disques et (heureusement) les systèmes d'exploitation sont plus fiables, beaucoup 
préfèrent n'avoir qu'une seule partition contenant tous leurs fichiers. D'un autre c\^oté, il est moins difficile
de sauvegarder (et de restaurer) une petite partition.
	
%	\meta more reasons for many partitions: users/temp files/spools
%	can't fill up all disks, readonly partitions less likely to corrupt, 
%	fsck is faster, limits losses a filesystem goes really wrong,
%	logging must not be disturbed, boots from >1023 cylinders do not
%	work on all BIOS's, /usr/local won't be disturbed by an upgrade,
%	easy to divide backup on many tapes, spare (scratch) partition for
%	experimentation (e.g., a new Linux distribution), scratch can
%	also be used to backup root during upgrades

Pour un petit disque dur (en supposant que l'on ne fasse pas de développement du noyau), la meilleure façon de faire est,
probablement, de n'avoir qu'une seule partition. Pour les gros disques, il est s\^urement préférable d'avoir quelques
grosses partitions, juste au cas où quelque chose n'irait pas. (On notera que les termes << petits >> et << gros >> sont 
relatifs ; les besoins en espace disque décident de leur seuil).

Si l'on a plusieurs disques, on peut vouloir avoir le système de fichiers racine (y compris \fn{/usr}) sur l'un, et
les répertoires utilisateurs sur un autre.

Il est souhaitable d'expérimenter un peu les différents procédés de partitionnement (avec le temps, pas seulement
lors de la première installation du système). Cela représente un peu de travail, car cela implique essentiellement
que l'on réinstalle plusieurs fois le système à partir de zéro, mais c'est la seule façon d'\^etre s\^ur que l'on fait
correctement les choses.

\subsection{Besoins en espace}

La distribution Linux que l'on installe donne quelques indications sur l'espace disque nécessaire aux différentes
configurations. Les programmes installés séparément procèdent de m\^eme. Cela aide à planifier l'usage de l'espace
disque, mais l'on doit se préparer au futur et réserver de l'espace supplémentaire pour des choses dont on pourrait
avoir besoin plus tard.

Le total nécessaire pour les fichiers utilisateurs dépend de ce que ceux-ci souhaitent faire. La plupart veulent disposer
d'autant d'espace que possible pour leurs fichiers, mais le montant qui leur conviendra varie beaucoup. Certains ne
font que du petit traitement de texte et se contenteront de quelques méga-octets, d'autres font du traitement d'images
complexes et auront besoin de giga-octets.

A ce propos, lorsqu'on compare des tailles de fichiers données en kilo-octets ou en méga-octets et un espace disque donné
en giga-octets, il est important de savoir que ces deux unités peuvent \^etre différentes. Quelques constructeurs de
disques préfèrent prétendre qu'un kilo-octets égale 1000 octets et qu'un méga-octets égale 1000 kilo-octets, alors que
le reste du monde de l'informatique utilise 1024 pour ces deux facteurs. En conséquence, mon disque dur de 345~Mo est,
en fait, un disque de 330~Mo.\footnote{Sic transit discus mundi.}

L'allocation de l'espace de swap est décrit dans la section~\ref{sec:swap-alloc}.

\subsection{Exemples d'allocation d'un disque dur}

	Je possédais un disque de 109~Mo, maintenant j'utilise un disque de 330~Mo. Voici comment, et pourquoi, j'ai
partitionné ces disques.

	J'ai partitionné mon disque de 109~Mo de nombreuses façons, lorsque mes besoins et les systèmes
d'exploitation que j'utilisais ont changé ; je décrirai deux scénarios typiques. Au début, j'utilisais MS-DOS et Linux.
Pour cela, j'avais besoin d'à peu près 20~Mo pour y mettre MS-DOS, un compilateur C, un éditeur, quelques utilitaires,
le programme sur lequel je travaillais et suffisamment d'espace disponible pour ne pas devenir claustrophobe. Pour Linux,
j'avais une partition de 10~Mo de swap, et le reste, soit 79~Mo était une seule partition contenant tous les fichiers 
Linux. J'ai essayé d'avoir des partitions séparées pour root,
\fn{/usr}, et \fn{/home}, mais il n'y avait jamais assez de place disponible à un endroit pour que cela soit 
intéressant.

	Lorsque je n'ai plus eu besoin de MS-DOS, j'ai repartitionné le disque de façon à avoir une partition de 12~Mo de
swap, et, à nouveau, tout le reste dans un seul système de fichiers.

	Le disque de 330~Mo est divisé en plusieurs partitions, de la façon suivante~:
		%
		\begin{quote}
		\begin{tabular}{r l}
	  	  5 MB & système de fichiers root\\
	 	 10 MB & partition de swap  \\
		180 MB & système de fichiers \fn{/usr} \\
		120 MB & système de fichiers \fn{/home}  \\
	 	 15 MB & partition vide.
		\end{tabular}
		\end{quote}
		%
La partition vide permet d'essayer des choses nécessitant leur propre partition, par exemple, pour essayer différentes
distributions Linux, ou comparer les vitesses des systèmes de fichiers. Lorsqu'elle ne sert à rien, elle est utilisée
comme espace de swap (j'aime avoir \emph{beaucoup} de fen\^etres ouvertes).

\subsection{Ajouter plus d'espace disque pour Linux}

Rajouter de l'espace disque pour Linux est facile, en tous cas lorsque le matériel nécessaire a été correctement installé
(cette installation sort du cadre de ce livre). On formate si nécessaire, puis on crée les partitions et les systèmes de 
fichiers comme décrit ci-dessus et on ajoute les lignes adéquates dans \fn{/etc/fstab} pour qu'ils soient
montés automatiquement.

\subsection{Astuces pour économiser l'espace disque}

La meilleure astuce pour économiser l'espace disque est d'éviter d'installer les programmes non nécessaires. La plupart des
distributions Linux permettent de n'installer qu'une partie des paquetages qu'elles contiennent, et en analysant ses
besoins on peut noter que l'on n'a pas besoin de la plupart d'entre eux. Cela permet d'économiser beaucoup de place car
de nombreux programmes sont plut\^ot gros. M\^eme si on a besoin d'un paquetage ou d'un programme particulier, on n'a pas 
forcément besoin de tout ce qu'il contient. Par exemple, la documentation en ligne n'est pas toute nécessaire, comme 
certains fichiers elisp de GNU Emacs, certaines fontes X11, ou certaines bibliothèques pour la programmation.

Si l'on ne peut désinstaller les paquetages, on peut se tourner vers la compression. Les programmes de compression
comme \cmd{gzip} ou \cmd{zip} compressent (et décompressent) les fichiers individuellement ou en groupe. Le système
\cmd{gzexe} compresse et décompresse les programmes de façon transparente pour l'utilisateur (les programmes
inutilisés sont compressés, puis décompressés lorsqu'ils sont utilisés). Le système expérimental \cmd{DouBle} compresse
tous les fichiers d'un système de fichiers de façon transparente pour les programmes qui les utilisent. (M\^eme
principe que des produits comme Stacker sous MS-DOS).





















