[Linux] formater 250 Go

Serge Schmitt sersch@::1
Mer 12 Déc 20:31:24 CET 2007


Bonjour,

Le Mercredi 12 Décembre 2007 16:42,
        René Bastian
a écrit pour nous :

> Bonjour,
>
> il me faut installer Linux sur un DD de 250 Go ;
> je pense :

Je suis en train d'envisager la même chose...

> tout en ext3

D'abord, ext3 est efficace (jamais perdu de données malgré des chocs 
divers), mais ralentit notablement les échanges. L'emplacement sur le 
disque en est moins crucial et à moins de traiter des Go de fichier en 
même temps,il sera difficile d'apprécier les différences.

D'autant que souvent on lance une autre appli en même temps qu'on charge 
des données, ou une autre se lance en tâche de fond, alors la tête de 
lecture zappe de toute manière !


> hda1 /boot entre 40 et 50 Mo Linux
> hda2 /                       Extended
> ---------
>      	hda5 20 Go 		pour /usr /etc ...
>      	hda6 32 Go   		swap
>      	hda7 50% du reste 	/home
> 	hda8 50% du reste	/data
>
> Y a-t-il un ordre préférentiel à donner lors du formatage
> pour que les partitions swap ou data soient accessibles le
> plus rapidement possible ; je crois qu'il y a(vait) une différence
> entre le bord et le centre mais je ne sais pas si ça a un sens ...

Toutes ces règles où on multipliait les partitions datent de l'ATAPI et 
des procs à 4 Mhz voire avant...

Le principale inconvénient : la multiplication des partitions multiplie 
aussi les risques de saturation de l'une d'elles. Commence alors le 
joyeux ballet des liens pour utiliser la place libre ici et là... Ça 
sent le vécu, non ? ;-)

Questions partoches, depuis quelques temps je me contente donc 
de : / , /swap et /home dans cet ordre. Je ne sauvegarde que /home 
et /etc. (*)

Sur le plan théorique, si je devais rajouter une partoche, au lieu 
de /boot, j'isolerai /tmp, pour me protéger des surcharges inopinées, 
mais bôf...

Pourquoi isoler /boot ? Pour gagner qq secondes au démarrage ?
Pourquoi isoler /usr ? La panne la plus fréquente est celle du dd 
lui-même, alors partoches isolées ou pas, c'est pareil.

/data : Si nas ou dd réseau, oui.
Sinon, si elle est sur le même disque, pourquoi l'isoler ? Je 
comprendrais aussi de la mettre sur un dd nomade extractible (eSata !), 
pour des raisons de discrétion, mais sur le même dd ?

Pour isoler les données en cas de panne, je trouve plus rationnel de 
multiplier les dd que de multiplier les partitions, et mieux de faire 
du mirroring. Et pour se protéger des erreurs ou des malveillances, 
yak'la sauvegarde !

Si tu mets une partoche /data, /home se suffira normalement de peu : si 
c'était pour moi, je mettrais une quinzaine de Go, pour être à l'aise, 
mais ça dépend of course comment les données sont organisées.

De plus le prix de la mémoire vive me ferait rompre la règle 
swap=1,5*mémoire_vive pour n'en mettre au contraire qu'une fraction, 
juste pour servir d'alerte... et pour que ça diminue le tendance à 
swapper, justement.

(*) En effet le reste se réinstalle.

En attendant la « continuité du service urgent » ;-) peut-être assurée à 
partir d'un live-cd qui peut même utiliser une copie rapidement faite 
de la sauvegarde.

Une Kubuntu est installée en ±1 heure sur une bécane contemporaine : ça 
doit être pareil pour les autres. La rapidité des connexions permet de 
rajouter les softs exotiques au fur et à mesure des besoins, peu de 
perte de temps donc, sinon conserver les .deb ou les sources non 
standards sur la sauvegarde pour les installer dans le même mouvement.

Accessoirement :

Je rêve même de travailler sous une Knoppix... Y'aka changer le cd en 
cas de nouvelle version, et avec des liens, toutes les données 
sensibles se stockent à l'extérieur de l'image /maison qui conserve la 
conf'.

Et si comme il y a qq années le home persistant devient inutilisable en 
changeant de version, y'a pratiquement à refaire que les liens dans un 
nouveau home persistant, et un peu de configuration. Avec bezef de 
mémoire vive, ça marche assez vite pour un usage courant. En tout cas 
suffisement comme système de secours, quand un « apt-get upgrade » se 
termine sur un écran noir, par exemple. Là aussi, ça sent le vécu, 
non ? ;-)

> ce n'est pas lors du lancement d'une appli que le temps est
> critique ; c'est l'accès aux données qui doit être rapide.

C'est vrai. Mais amha c'est peu perceptible en usage courant sur les 
machines actuelles, comme dit.

> Merci pour vos conseils

De rien ! ;-)
-- 
Serge
« ...nous sommes entrés dans l’ère de la démocratie contemplative. »
Michel Wieworka - http://www.liberation.fr/rebonds/292970.FR.php


Plus d'informations sur la liste de diffusion linux