à Noël dernier, mon disque de 60 Go (sur lequel Linux n'occupait qu'une
place minime) est mort subitement :'(
J'en ai profité pour me reconstruire un système sur un disque de 20 Go prêté
par un copain (là on est déjà à 11 Go Linux pour 9 Go XP : le pingouin
gagne du terrain :).
J'ai maintenant un disque de remplacement pour mon nouveau système : 120 Go
(de quoi voir venir !)
Je vais ainsi pouvoir mettre en application les récents posts sur les
recopies de partitions.
Or, tant qu'à repartir sur de nouvelles bases autant faire quelque chose de
correct et je m'interrogeais sur la répartition idéale d'un système.
Il se trouve qu'un certain Tichou ;^) disait récemment ici
<401a8429$0$22337$626a54ce@news.free.fr>
> Une partition primaire /dev/hda1 pour /boot, une partition étendue
> /dev/hda2, une partition primaire /dev/hda3 ou /dev/hda4 pour swap.
> Ensuite dans la partition étendue, une partition logique /dev/hda5 pour /,
> une /dev/hda6 pour /tmp, une /dev/hda7 pour /usr, une /dev/hda8 pour /var,
> une /dev/hda9 pour /home et une /dev/hda10 pour /usr/local ou /usr/src.
Pourriez vous approfondir ceci en mettant des tailles en face de cette
répartition ?
Je n'ai pas la pratique de ce genre de répartition, jusqu'alors je me
contentais de segmenter en système/home/swap.
Sans troller ni entrer dans une querelle d'église, est-ce qu'un découpage
plus fin est préférable ?
Je n'ai pas le recul pour estimer la taille des différentes partitions ni
pour l'espace libre à réserver; je suppose que tmp, home et usr sont celles
qui fluctuent le plus...
Quelle taille de swap est recommandée (j'ai souvenir que > 256 Mo est
inutile, bien que mon swap actuel fasse 800 Mo) ? Est-ce toujours relatif à
la RAM ? Je dispose de 512 Mo.
Les hypothèses de travail sont les suivantes ;o)
- on dispose d'un disque tout neuf et vierge de 120 Go
- je compte tout de même réserver un place pour Xp de 10 Go max
- j'aimerais aussi ménager une partition d'échange ouin-ouin / linux (10 Go
au moins, voire plus)
Je regarde la place occupée actuelle et je rajoute 10% ? :o)
il vaut mieux voir large, je ne sais pas pourquoi, mais mes disques ont horreur du vide :)
j'aime bien avoir mini 30% d'espace libre a la creation
J'me doute que pour /boot ou /etc ça doit pas varier de façon énAUrme :) ?
GERBIER Eric
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Sébastien Kirche wrote:
On 10 Feb 2004, GERBIER Eric wrote:
J'me doute que pour /boot ou /etc ça doit pas varier de façon énAUrme :) ?
ben ca depend : si je taille une partition minimale de quelques petits mega et que je rajoute quelques noyaux en tests, j'arrive a doubler la place occuppee
pour /etc, c'est assez stable -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
J'me doute que pour /boot ou /etc ça doit pas varier de façon énAUrme :) ?
ben ca depend : si je taille une partition minimale de quelques petits mega
et que je rajoute quelques noyaux en tests, j'arrive a doubler la place occuppee
pour /etc, c'est assez stable
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
J'me doute que pour /boot ou /etc ça doit pas varier de façon énAUrme :) ?
ben ca depend : si je taille une partition minimale de quelques petits mega et que je rajoute quelques noyaux en tests, j'arrive a doubler la place occuppee
pour /etc, c'est assez stable -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
Debian, je sais au moins que le module existe : le l'ai désactivé récemment car je ne voyais pas à quoi cela servait :) Oui je sais que c'est dispo sous Debian, je SUIS sous Debian (serveur en
Woody, PC et portable en Sid) :P La seule inconnue pour ma part c'est de savoir s'il est possible dès le CD de boot de créer un LVM sur ton disque. Je ne souviens pas d'une options de se genre dans le debian-installer. Personnelement j'ai fait ça en 2 étapes (install mini, maj du kernel avec LVM, migration).
Ok, et sur une installation existante, on peut migrer le fs en place sans soucis juste en lançant le bon module ? Sans problème, tu crée ton LVM sur une nouvelle partition, tu migres les
données et tu rajoutes ensuite l'ancienne partition dans le LVM.
Sébastien Kirche wrote:
Debian, je sais au moins que le module existe : le l'ai désactivé récemment
car je ne voyais pas à quoi cela servait :)
Oui je sais que c'est dispo sous Debian, je SUIS sous Debian (serveur en
Woody, PC et portable en Sid) :P
La seule inconnue pour ma part c'est de savoir s'il est possible dès le
CD de boot de créer un LVM sur ton disque. Je ne souviens pas d'une
options de se genre dans le debian-installer. Personnelement j'ai fait
ça en 2 étapes (install mini, maj du kernel avec LVM, migration).
Ok, et sur une installation existante, on peut migrer le fs en place sans
soucis juste en lançant le bon module ?
Sans problème, tu crée ton LVM sur une nouvelle partition, tu migres les
données et tu rajoutes ensuite l'ancienne partition dans le LVM.
Debian, je sais au moins que le module existe : le l'ai désactivé récemment car je ne voyais pas à quoi cela servait :) Oui je sais que c'est dispo sous Debian, je SUIS sous Debian (serveur en
Woody, PC et portable en Sid) :P La seule inconnue pour ma part c'est de savoir s'il est possible dès le CD de boot de créer un LVM sur ton disque. Je ne souviens pas d'une options de se genre dans le debian-installer. Personnelement j'ai fait ça en 2 étapes (install mini, maj du kernel avec LVM, migration).
Ok, et sur une installation existante, on peut migrer le fs en place sans soucis juste en lançant le bon module ? Sans problème, tu crée ton LVM sur une nouvelle partition, tu migres les
données et tu rajoutes ensuite l'ancienne partition dans le LVM.
Alexis Guillaume
Je n'ai pas la pratique de ce genre de répartition, jusqu'alors je me contentais de segmenter en système/home/swap. Sans troller ni entrer dans une querelle d'église, est-ce qu'un découpage plus fin est préférable ?
Je ne pense pas. Personnellement je découpe mon disque en système1/système2/home/swap ; il est toujours pratique de pouvoir tester une deuxième distrib sans virer la première (même si en fait ça ne m'est jamais arrivé !). Cette deuxième partition fait aussi un bon temp utilisateur (tu sais que tout ce que tu mets dedans est virable, mais ça persiste quand même au reboot).
-- Alexis Guillaume <http://cowsoft.free.fr> : ressources universitaires en vrac
"Il est minuit. La pluie fouette les vitres."
Je n'ai pas la pratique de ce genre de répartition, jusqu'alors je me
contentais de segmenter en système/home/swap.
Sans troller ni entrer dans une querelle d'église, est-ce qu'un découpage
plus fin est préférable ?
Je ne pense pas. Personnellement je découpe mon disque en
système1/système2/home/swap ; il est toujours pratique de pouvoir tester
une deuxième distrib sans virer la première (même si en fait ça ne m'est
jamais arrivé !). Cette deuxième partition fait aussi un bon temp
utilisateur (tu sais que tout ce que tu mets dedans est virable, mais ça
persiste quand même au reboot).
--
Alexis Guillaume
<http://cowsoft.free.fr> : ressources universitaires en vrac
Je n'ai pas la pratique de ce genre de répartition, jusqu'alors je me contentais de segmenter en système/home/swap. Sans troller ni entrer dans une querelle d'église, est-ce qu'un découpage plus fin est préférable ?
Je ne pense pas. Personnellement je découpe mon disque en système1/système2/home/swap ; il est toujours pratique de pouvoir tester une deuxième distrib sans virer la première (même si en fait ça ne m'est jamais arrivé !). Cette deuxième partition fait aussi un bon temp utilisateur (tu sais que tout ce que tu mets dedans est virable, mais ça persiste quand même au reboot).
-- Alexis Guillaume <http://cowsoft.free.fr> : ressources universitaires en vrac
"Il est minuit. La pluie fouette les vitres."
TiChou
Dans l'article news:, Sébastien Kirche écrivait :
Bonsoir,
Bonsoir,
J'ai maintenant un disque de remplacement pour mon nouveau système : 120 Go
(de quoi voir venir !) Je vais ainsi pouvoir mettre en application les récents posts sur les
recopies de partitions. Or, tant qu'à repartir sur de nouvelles bases autant faire quelque chose de
correct et je m'interrogeais sur la répartition idéale d'un système.
Il se trouve qu'un certain Tichou ;^) disait récemment ici <401a8429$0$22337$
Une partition primaire /dev/hda1 pour /boot, une partition étendue /dev/hda2, une partition primaire /dev/hda3 ou /dev/hda4 pour swap. Ensuite dans la partition étendue, une partition logique /dev/hda5 pour /,
une /dev/hda6 pour /tmp, une /dev/hda7 pour /usr, une /dev/hda8 pour /var,
une /dev/hda9 pour /home et une /dev/hda10 pour /usr/local ou /usr/src.
Pourriez vous approfondir ceci en mettant des tailles en face de cette
répartition ?
Dans le post suivant apportais plus de précisions : <3ff72a35$0$7142$ (http://groups.google.fr/groups?selm?f72a35$0$7142$)
Je n'ai pas la pratique de ce genre de répartition, jusqu'alors je me
contentais de segmenter en système/home/swap. Sans troller ni entrer dans une querelle d'église, est-ce qu'un découpage
plus fin est préférable ?
Tout dépend de l'utilisation de la machine. Dans le cas d'un serveur, oui. Dans le cas d'une station de travail, moins.
Je n'ai pas le recul pour estimer la taille des différentes partitions ni
pour l'espace libre à réserver; je suppose que tmp, home et usr sont celles
qui fluctuent le plus...
/ ext3 ou reiserfs (journalisation très recommandée), options noatime, contenant obligatoirement les points de montage et les répertoires /bin, /sbin, /lib, /etc, /dev, /root, /mnt. La taille, 150Mo suffisent mais attention à ne pas accumuler différentes versions de kernels et les modules associés dans /lib/modules.
/boot avec un système de fichier standard comme ext2 (journalisation inutile) permettant d'être accessible avec sans problème avec disquette et CD de rescue, d'éviter de corrompre l'image du kernel (options noauto et ro), de sécuriser le système en empêchant les utilisateurs de connaître rapidement les options du kernel. La taille, à peine quelques dizaines de Mo.
/tmp on évite à un utilisateur malveillant de saturer l'espace disque sur le système, utilisé avec un système de fichier comme reiserfs même si la journalisation est peu utile. La taille, 250Mo suffisent largement dans la majorité des cas, on peut tout de même aller jusqu'à 500Mo.
/usr dépend du type d'utilisation de la machine. Window manager ou non, applications multimédias ou non. Système de fichier ext3, options noatime et ro (à part lors de la mise à jour et lors d'installation d'applications, il n'y aucune raison que /usr soit accessible en écriture). La taille, 5Go devrait faire l'affaire. On peut aussi éventuellement séparer /usr/local, permettant lors d'une réinstallation du système de garder les applications compilées par sois même.
/var la partition la plus critique, dépend beaucoup de l'utilisation de la machine, de la taille des spool, des distributions (sous Gentoo /var/tmp peut prendre pas loin de 700Mo lors d'une compilation XFree), de la rotation des fichiers de logs. Le système de fichier reiserfs dans le cas d'un gros serveur de mail, option noatime indispensable. La taille, 1 à 2Go, voir beaucoup plus sur machines de production.
/home dépend beaucoup de l'utilisation de la machine et de son nombre d'utilisateurs. Système de fichiers ext3 en général. La taille, le reste de l'espace libre.
J'ai pour habitude aussi de créer une partition /server dans laquelle je chroote tous mes services (dns, dhcp, www, samba, serveurs de jeux, nfs). Cela permet de bien sécuriser ces services du reste du système. La taille, variable, dépend de l'utilisation des services de fichiers de masse, plusieurs Go.
Quelle taille de swap est recommandée (j'ai souvenir que > 256 Mo est
inutile, bien que mon swap actuel fasse 800 Mo) ? Est-ce toujours relatif à
la RAM ? Je dispose de 512 Mo.
Jusqu'à 256Mo de RAM, je dirais le double de celle ci. Au delà, la même taille que la RAM. Et pour les machines de productions, cela dépend si elles sont susceptibles d'avoir de grosse montée de charge. Mais un système qui a largement plus de SWAP que de RAM est un système qui est mal adaptée à la machine.
Les hypothèses de travail sont les suivantes ;o) - on dispose d'un disque tout neuf et vierge de 120 Go - je compte tout de même réserver un place pour Xp de 10 Go max - j'aimerais aussi ménager une partition d'échange ouin-ouin / linux (10 Go
au moins, voire plus)
Faut prévoir pour la partition d'échange un système de fichier FAT, le seul que les deux systèmes vont gérer sans conflit.
J'aimerais beaucoup en savoir plus.
Il existe un Partition-HOWTO, peut être un peu obsolète, mais à voir tout de même. Et de manière générale, c'est votre utilisation avec vos habitudes et vos besoins qui vous permettront de déterminer au mieux le nombre et la taille des partitions.
Cordialement
Je vous en prie.
-- TiChou
Dans l'article news:85hdxzdgv1.fsf@free.fr,
Sébastien Kirche <sebastien.kirche.no@spam.free.fr.invalid> écrivait :
Bonsoir,
Bonsoir,
J'ai maintenant un disque de remplacement pour mon nouveau système : 120
Go
(de quoi voir venir !)
Je vais ainsi pouvoir mettre en application les récents posts sur
les
recopies de partitions.
Or, tant qu'à repartir sur de nouvelles bases autant faire quelque chose
de
correct et je m'interrogeais sur la répartition idéale d'un système.
Il se trouve qu'un certain Tichou ;^) disait récemment ici
<401a8429$0$22337$626a54ce@news.free.fr>
Une partition primaire /dev/hda1 pour /boot, une partition étendue
/dev/hda2, une partition primaire /dev/hda3 ou /dev/hda4 pour swap.
Ensuite dans la partition étendue, une partition logique /dev/hda5 pour
/,
une /dev/hda6 pour /tmp, une /dev/hda7 pour /usr, une /dev/hda8 pour
/var,
une /dev/hda9 pour /home et une /dev/hda10 pour /usr/local ou /usr/src.
Pourriez vous approfondir ceci en mettant des tailles en face de
cette
répartition ?
Dans le post suivant apportais plus de précisions :
<3ff72a35$0$7142$626a54ce@news.free.fr>
(http://groups.google.fr/groups?selm?f72a35$0$7142$626a54ce@news.free.fr)
Je n'ai pas la pratique de ce genre de répartition, jusqu'alors je
me
contentais de segmenter en système/home/swap.
Sans troller ni entrer dans une querelle d'église, est-ce qu'un
découpage
plus fin est préférable ?
Tout dépend de l'utilisation de la machine. Dans le cas d'un serveur, oui.
Dans le cas d'une station de travail, moins.
Je n'ai pas le recul pour estimer la taille des différentes partitions
ni
pour l'espace libre à réserver; je suppose que tmp, home et usr sont
celles
qui fluctuent le plus...
/ ext3 ou reiserfs (journalisation très recommandée), options noatime,
contenant obligatoirement les points de montage et les répertoires /bin,
/sbin, /lib, /etc, /dev, /root, /mnt. La taille, 150Mo suffisent mais
attention à ne pas accumuler différentes versions de kernels et les modules
associés dans /lib/modules.
/boot avec un système de fichier standard comme ext2 (journalisation
inutile) permettant d'être accessible avec sans problème avec disquette et
CD de rescue, d'éviter de corrompre l'image du kernel (options noauto et
ro), de sécuriser le système en empêchant les utilisateurs de connaître
rapidement les options du kernel. La taille, à peine quelques dizaines de
Mo.
/tmp on évite à un utilisateur malveillant de saturer l'espace disque sur le
système, utilisé avec un système de fichier comme reiserfs même si la
journalisation est peu utile. La taille, 250Mo suffisent largement dans la
majorité des cas, on peut tout de même aller jusqu'à 500Mo.
/usr dépend du type d'utilisation de la machine. Window manager ou non,
applications multimédias ou non. Système de fichier ext3, options noatime et
ro (à part lors de la mise à jour et lors d'installation d'applications, il
n'y aucune raison que /usr soit accessible en écriture). La taille, 5Go
devrait faire l'affaire. On peut aussi éventuellement séparer /usr/local,
permettant lors d'une réinstallation du système de garder les applications
compilées par sois même.
/var la partition la plus critique, dépend beaucoup de l'utilisation de la
machine, de la taille des spool, des distributions (sous Gentoo /var/tmp
peut prendre pas loin de 700Mo lors d'une compilation XFree), de la rotation
des fichiers de logs. Le système de fichier reiserfs dans le cas d'un gros
serveur de mail, option noatime indispensable. La taille, 1 à 2Go, voir
beaucoup plus sur machines de production.
/home dépend beaucoup de l'utilisation de la machine et de son nombre
d'utilisateurs. Système de fichiers ext3 en général. La taille, le reste de
l'espace libre.
J'ai pour habitude aussi de créer une partition /server dans laquelle je
chroote tous mes services (dns, dhcp, www, samba, serveurs de jeux, nfs).
Cela permet de bien sécuriser ces services du reste du système. La taille,
variable, dépend de l'utilisation des services de fichiers de masse,
plusieurs Go.
Quelle taille de swap est recommandée (j'ai souvenir que > 256 Mo
est
inutile, bien que mon swap actuel fasse 800 Mo) ? Est-ce toujours relatif
à
la RAM ? Je dispose de 512 Mo.
Jusqu'à 256Mo de RAM, je dirais le double de celle ci. Au delà, la même
taille que la RAM. Et pour les machines de productions, cela dépend si elles
sont susceptibles d'avoir de grosse montée de charge. Mais un système qui a
largement plus de SWAP que de RAM est un système qui est mal adaptée à la
machine.
Les hypothèses de travail sont les suivantes ;o)
- on dispose d'un disque tout neuf et vierge de 120 Go
- je compte tout de même réserver un place pour Xp de 10 Go max
- j'aimerais aussi ménager une partition d'échange ouin-ouin / linux (10
Go
au moins, voire plus)
Faut prévoir pour la partition d'échange un système de fichier FAT, le seul
que les deux systèmes vont gérer sans conflit.
J'aimerais beaucoup en savoir plus.
Il existe un Partition-HOWTO, peut être un peu obsolète, mais à voir tout de
même.
Et de manière générale, c'est votre utilisation avec vos habitudes et vos
besoins qui vous permettront de déterminer au mieux le nombre et la taille
des partitions.
J'ai maintenant un disque de remplacement pour mon nouveau système : 120 Go
(de quoi voir venir !) Je vais ainsi pouvoir mettre en application les récents posts sur les
recopies de partitions. Or, tant qu'à repartir sur de nouvelles bases autant faire quelque chose de
correct et je m'interrogeais sur la répartition idéale d'un système.
Il se trouve qu'un certain Tichou ;^) disait récemment ici <401a8429$0$22337$
Une partition primaire /dev/hda1 pour /boot, une partition étendue /dev/hda2, une partition primaire /dev/hda3 ou /dev/hda4 pour swap. Ensuite dans la partition étendue, une partition logique /dev/hda5 pour /,
une /dev/hda6 pour /tmp, une /dev/hda7 pour /usr, une /dev/hda8 pour /var,
une /dev/hda9 pour /home et une /dev/hda10 pour /usr/local ou /usr/src.
Pourriez vous approfondir ceci en mettant des tailles en face de cette
répartition ?
Dans le post suivant apportais plus de précisions : <3ff72a35$0$7142$ (http://groups.google.fr/groups?selm?f72a35$0$7142$)
Je n'ai pas la pratique de ce genre de répartition, jusqu'alors je me
contentais de segmenter en système/home/swap. Sans troller ni entrer dans une querelle d'église, est-ce qu'un découpage
plus fin est préférable ?
Tout dépend de l'utilisation de la machine. Dans le cas d'un serveur, oui. Dans le cas d'une station de travail, moins.
Je n'ai pas le recul pour estimer la taille des différentes partitions ni
pour l'espace libre à réserver; je suppose que tmp, home et usr sont celles
qui fluctuent le plus...
/ ext3 ou reiserfs (journalisation très recommandée), options noatime, contenant obligatoirement les points de montage et les répertoires /bin, /sbin, /lib, /etc, /dev, /root, /mnt. La taille, 150Mo suffisent mais attention à ne pas accumuler différentes versions de kernels et les modules associés dans /lib/modules.
/boot avec un système de fichier standard comme ext2 (journalisation inutile) permettant d'être accessible avec sans problème avec disquette et CD de rescue, d'éviter de corrompre l'image du kernel (options noauto et ro), de sécuriser le système en empêchant les utilisateurs de connaître rapidement les options du kernel. La taille, à peine quelques dizaines de Mo.
/tmp on évite à un utilisateur malveillant de saturer l'espace disque sur le système, utilisé avec un système de fichier comme reiserfs même si la journalisation est peu utile. La taille, 250Mo suffisent largement dans la majorité des cas, on peut tout de même aller jusqu'à 500Mo.
/usr dépend du type d'utilisation de la machine. Window manager ou non, applications multimédias ou non. Système de fichier ext3, options noatime et ro (à part lors de la mise à jour et lors d'installation d'applications, il n'y aucune raison que /usr soit accessible en écriture). La taille, 5Go devrait faire l'affaire. On peut aussi éventuellement séparer /usr/local, permettant lors d'une réinstallation du système de garder les applications compilées par sois même.
/var la partition la plus critique, dépend beaucoup de l'utilisation de la machine, de la taille des spool, des distributions (sous Gentoo /var/tmp peut prendre pas loin de 700Mo lors d'une compilation XFree), de la rotation des fichiers de logs. Le système de fichier reiserfs dans le cas d'un gros serveur de mail, option noatime indispensable. La taille, 1 à 2Go, voir beaucoup plus sur machines de production.
/home dépend beaucoup de l'utilisation de la machine et de son nombre d'utilisateurs. Système de fichiers ext3 en général. La taille, le reste de l'espace libre.
J'ai pour habitude aussi de créer une partition /server dans laquelle je chroote tous mes services (dns, dhcp, www, samba, serveurs de jeux, nfs). Cela permet de bien sécuriser ces services du reste du système. La taille, variable, dépend de l'utilisation des services de fichiers de masse, plusieurs Go.
Quelle taille de swap est recommandée (j'ai souvenir que > 256 Mo est
inutile, bien que mon swap actuel fasse 800 Mo) ? Est-ce toujours relatif à
la RAM ? Je dispose de 512 Mo.
Jusqu'à 256Mo de RAM, je dirais le double de celle ci. Au delà, la même taille que la RAM. Et pour les machines de productions, cela dépend si elles sont susceptibles d'avoir de grosse montée de charge. Mais un système qui a largement plus de SWAP que de RAM est un système qui est mal adaptée à la machine.
Les hypothèses de travail sont les suivantes ;o) - on dispose d'un disque tout neuf et vierge de 120 Go - je compte tout de même réserver un place pour Xp de 10 Go max - j'aimerais aussi ménager une partition d'échange ouin-ouin / linux (10 Go
au moins, voire plus)
Faut prévoir pour la partition d'échange un système de fichier FAT, le seul que les deux systèmes vont gérer sans conflit.
J'aimerais beaucoup en savoir plus.
Il existe un Partition-HOWTO, peut être un peu obsolète, mais à voir tout de même. Et de manière générale, c'est votre utilisation avec vos habitudes et vos besoins qui vous permettront de déterminer au mieux le nombre et la taille des partitions.
Cordialement
Je vous en prie.
-- TiChou
Daniel Déchelotte
| Il se trouve qu'un certain Tichou ;^) disait récemment ici | <401a8429$0$22337$ | | [...]
Je me flatte d'avoir produit une stucture tres similaire.
Voila ce que j'ai fait sur mon DD de 40 Go: /dev/hda1 100M / /dev/hda2 256M swap /dev/hda3 le reste etendue
Tout en ext3 "naturellement". C'est assez "pedant" d'avoir autant de partitions, mais mon idee est: - de monter /usr en lecture seule (a terme) (c'est un poil parano) - d'empecher /var et /tmp de trop grossir, au cas ou qqch part en sucette. Mais je voulais que /tmp puisse contenir, par exemple, une iso. J'espere pouvoir les monter avec des options un peu parano (noexec, nosuid). - comme /usr sera en lecture seule, et que je veux pouvoir compiler des noyaux, j'ai un /usr/src. Il est peut-etre un peu petit... - et bien sur un /home
Mon idee est d'experimenter un truc plus complique que le strictement necessaire, de facon a m'amuser/apprendre plus que necessaire. :)
Et ne sois pas effraye d'etre coince par une partition pleine. Si /usr est pleine, je fais un lien symbolique /usr/local/openoffice -> /home/openoffice et le probleme est regle. C'est beaucoup plus souple qu'en FAT, ou si C: est plein, D: est vide, mais que le programme *veut* s'installer sur C:, t'es dans la mouise. Amuse-toi, donc !
Enfin, avec plus d'espace, j'aurais grossi /usr a 15G, /usr/src a 10G, laisse inchanges /, /var et /tmp et tout donne a /home. Et s'il te venait a l'esprit d'utiliser ta machine comme un (gros) serveur mail ou web, il faudra augmenter serieusement /var.
Have fun!
-- Daniel Déchelotte http://yo.dan.free.fr/
| Il se trouve qu'un certain Tichou ;^) disait récemment ici
| <401a8429$0$22337$626a54ce@news.free.fr>
|
| [...]
Je me flatte d'avoir produit une stucture tres similaire.
Voila ce que j'ai fait sur mon DD de 40 Go:
/dev/hda1 100M /
/dev/hda2 256M swap
/dev/hda3 le reste etendue
Tout en ext3 "naturellement". C'est assez "pedant" d'avoir autant de
partitions, mais mon idee est:
- de monter /usr en lecture seule (a terme) (c'est un poil parano)
- d'empecher /var et /tmp de trop grossir, au cas ou qqch part en
sucette. Mais je voulais que /tmp puisse contenir, par exemple,
une iso. J'espere pouvoir les monter avec des options un peu
parano (noexec, nosuid).
- comme /usr sera en lecture seule, et que je veux pouvoir compiler
des noyaux, j'ai un /usr/src. Il est peut-etre un peu petit...
- et bien sur un /home
Mon idee est d'experimenter un truc plus complique que le strictement
necessaire, de facon a m'amuser/apprendre plus que necessaire. :)
Et ne sois pas effraye d'etre coince par une partition pleine. Si /usr
est pleine, je fais un lien symbolique /usr/local/openoffice ->
/home/openoffice et le probleme est regle. C'est beaucoup plus souple
qu'en FAT, ou si C: est plein, D: est vide, mais que le programme
*veut* s'installer sur C:, t'es dans la mouise. Amuse-toi, donc !
Enfin, avec plus d'espace, j'aurais grossi /usr a 15G, /usr/src a 10G,
laisse inchanges /, /var et /tmp et tout donne a /home. Et s'il te
venait a l'esprit d'utiliser ta machine comme un (gros) serveur mail ou
web, il faudra augmenter serieusement /var.
Tout en ext3 "naturellement". C'est assez "pedant" d'avoir autant de partitions, mais mon idee est: - de monter /usr en lecture seule (a terme) (c'est un poil parano) - d'empecher /var et /tmp de trop grossir, au cas ou qqch part en sucette. Mais je voulais que /tmp puisse contenir, par exemple, une iso. J'espere pouvoir les monter avec des options un peu parano (noexec, nosuid). - comme /usr sera en lecture seule, et que je veux pouvoir compiler des noyaux, j'ai un /usr/src. Il est peut-etre un peu petit... - et bien sur un /home
Mon idee est d'experimenter un truc plus complique que le strictement necessaire, de facon a m'amuser/apprendre plus que necessaire. :)
Et ne sois pas effraye d'etre coince par une partition pleine. Si /usr est pleine, je fais un lien symbolique /usr/local/openoffice -> /home/openoffice et le probleme est regle. C'est beaucoup plus souple qu'en FAT, ou si C: est plein, D: est vide, mais que le programme *veut* s'installer sur C:, t'es dans la mouise. Amuse-toi, donc !
Enfin, avec plus d'espace, j'aurais grossi /usr a 15G, /usr/src a 10G, laisse inchanges /, /var et /tmp et tout donne a /home. Et s'il te venait a l'esprit d'utiliser ta machine comme un (gros) serveur mail ou web, il faudra augmenter serieusement /var.
Have fun!
-- Daniel Déchelotte http://yo.dan.free.fr/
Thomas Nemeth
Le mar 10 fév 2004 à 19:20, Daniel Déchelotte a tapoté : | | | Il se trouve qu'un certain Tichou ;^) disait récemment ici | | <401a8429$0$22337$ | | | | [...] | | Je me flatte d'avoir produit une stucture tres similaire. | | Voila ce que j'ai fait sur mon DD de 40 Go: | /dev/hda1 100M / [...] | | Tout en ext3 "naturellement". C'est assez "pedant" d'avoir autant de | partitions, mais mon idee est:
Non, ce n'est pas pédant. J'en ai bien plus sur un serveur. Le tout est de savoir ce qu'on veut faire de sa babasse. Pour les stations, avoir une découpe du système de fichier trop fine peut être chiante à la réinstallation. Mais pour un serveur, c'est bien pratique.
| - de monter /usr en lecture seule (a terme) (c'est un poil parano) | - d'empecher /var et /tmp de trop grossir, au cas ou qqch part en | sucette. Mais je voulais que /tmp puisse contenir, par exemple, | une iso. J'espere pouvoir les monter avec des options un peu | parano (noexec, nosuid). | - comme /usr sera en lecture seule, et que je veux pouvoir compiler | des noyaux, j'ai un /usr/src. Il est peut-etre un peu petit... | - et bien sur un /home
- de "tuner" certains éléments des systèmes de fichiers pour des utilisations particulières (serveurs de mails, de news, de BD, de fichiers, toussa) en fonction de la taille moyenne des fichiers sur la partition : on adapte le FS et le nombre d'inodes etc. - de permettre des exports NFS simplifiés et différents en fonction de chaque architecture (ici PC, Sparc).
| Et ne sois pas effraye d'etre coince par une partition pleine. Si /usr | est pleine, je fais un lien symbolique /usr/local/openoffice -> | /home/openoffice et le probleme est regle. C'est beaucoup plus souple
Exactement.
Thomas -- Les gadgets, les pifises et les pois sauteurs, Rahan, Gai-luron, Gaston, Boule et Bill, les histoires de l'Oncle Paul, Sam et l'ours, Le vieux Nick et Barbe noire, la rubrique-à-brac, le grand Duduche ... ahhh ! -+- MB in: Guide du Cabaliste Usenet - La nostalgie persiffle et signe -+-
Le mar 10 fév 2004 à 19:20, Daniel Déchelotte a tapoté :
|
| | Il se trouve qu'un certain Tichou ;^) disait récemment ici
| | <401a8429$0$22337$626a54ce@news.free.fr>
| |
| | [...]
|
| Je me flatte d'avoir produit une stucture tres similaire.
|
| Voila ce que j'ai fait sur mon DD de 40 Go:
| /dev/hda1 100M /
[...]
|
| Tout en ext3 "naturellement". C'est assez "pedant" d'avoir autant de
| partitions, mais mon idee est:
Non, ce n'est pas pédant. J'en ai bien plus sur un serveur. Le tout
est de savoir ce qu'on veut faire de sa babasse. Pour les stations,
avoir une découpe du système de fichier trop fine peut être chiante
à la réinstallation. Mais pour un serveur, c'est bien pratique.
| - de monter /usr en lecture seule (a terme) (c'est un poil parano)
| - d'empecher /var et /tmp de trop grossir, au cas ou qqch part en
| sucette. Mais je voulais que /tmp puisse contenir, par exemple,
| une iso. J'espere pouvoir les monter avec des options un peu
| parano (noexec, nosuid).
| - comme /usr sera en lecture seule, et que je veux pouvoir compiler
| des noyaux, j'ai un /usr/src. Il est peut-etre un peu petit...
| - et bien sur un /home
- de "tuner" certains éléments des systèmes de fichiers pour des
utilisations particulières (serveurs de mails, de news, de BD,
de fichiers, toussa) en fonction de la taille moyenne des fichiers
sur la partition : on adapte le FS et le nombre d'inodes etc.
- de permettre des exports NFS simplifiés et différents en fonction
de chaque architecture (ici PC, Sparc).
| Et ne sois pas effraye d'etre coince par une partition pleine. Si /usr
| est pleine, je fais un lien symbolique /usr/local/openoffice ->
| /home/openoffice et le probleme est regle. C'est beaucoup plus souple
Exactement.
Thomas
--
Les gadgets, les pifises et les pois sauteurs, Rahan, Gai-luron, Gaston,
Boule et Bill, les histoires de l'Oncle Paul, Sam et l'ours, Le vieux
Nick et Barbe noire, la rubrique-à-brac, le grand Duduche ... ahhh !
-+- MB in: Guide du Cabaliste Usenet - La nostalgie persiffle et signe -+-
Le mar 10 fév 2004 à 19:20, Daniel Déchelotte a tapoté : | | | Il se trouve qu'un certain Tichou ;^) disait récemment ici | | <401a8429$0$22337$ | | | | [...] | | Je me flatte d'avoir produit une stucture tres similaire. | | Voila ce que j'ai fait sur mon DD de 40 Go: | /dev/hda1 100M / [...] | | Tout en ext3 "naturellement". C'est assez "pedant" d'avoir autant de | partitions, mais mon idee est:
Non, ce n'est pas pédant. J'en ai bien plus sur un serveur. Le tout est de savoir ce qu'on veut faire de sa babasse. Pour les stations, avoir une découpe du système de fichier trop fine peut être chiante à la réinstallation. Mais pour un serveur, c'est bien pratique.
| - de monter /usr en lecture seule (a terme) (c'est un poil parano) | - d'empecher /var et /tmp de trop grossir, au cas ou qqch part en | sucette. Mais je voulais que /tmp puisse contenir, par exemple, | une iso. J'espere pouvoir les monter avec des options un peu | parano (noexec, nosuid). | - comme /usr sera en lecture seule, et que je veux pouvoir compiler | des noyaux, j'ai un /usr/src. Il est peut-etre un peu petit... | - et bien sur un /home
- de "tuner" certains éléments des systèmes de fichiers pour des utilisations particulières (serveurs de mails, de news, de BD, de fichiers, toussa) en fonction de la taille moyenne des fichiers sur la partition : on adapte le FS et le nombre d'inodes etc. - de permettre des exports NFS simplifiés et différents en fonction de chaque architecture (ici PC, Sparc).
| Et ne sois pas effraye d'etre coince par une partition pleine. Si /usr | est pleine, je fais un lien symbolique /usr/local/openoffice -> | /home/openoffice et le probleme est regle. C'est beaucoup plus souple
Exactement.
Thomas -- Les gadgets, les pifises et les pois sauteurs, Rahan, Gai-luron, Gaston, Boule et Bill, les histoires de l'Oncle Paul, Sam et l'ours, Le vieux Nick et Barbe noire, la rubrique-à-brac, le grand Duduche ... ahhh ! -+- MB in: Guide du Cabaliste Usenet - La nostalgie persiffle et signe -+-
Cem
Le 10-02-2004, Daniel Déchelotte a écrit :
Voila ce que j'ai fait sur mon DD de 40 Go: /dev/hda1 100M / /dev/hda2 256M swap /dev/hda3 le reste etendue
Je me pose justement la question des systèmes de fichiers à utiliser. /usr et /usr/src sont relativement statiques (en dehors du moment où on installe des logiciels). Et /tmp ne contient rien qu'on ne puisse perdre. On peut même le monter sur /dev/shm (dans ce cas il vaut peut-être mieux augmenter la taille de swap). Journaliser ces partitions me paraît peu utile et même pénalisant pour la performance. Donc, je dirais / /var et /home en ext3 (ou autre système journalisé). /usr /usr/src et /tmp en ext2 Qu'en pensez vous?
Le 10-02-2004, Daniel Déchelotte <maitre_yodan@fr.club-internet.invalid>
a écrit :
Voila ce que j'ai fait sur mon DD de 40 Go:
/dev/hda1 100M /
/dev/hda2 256M swap
/dev/hda3 le reste etendue
Je me pose justement la question des systèmes de fichiers à utiliser.
/usr et /usr/src sont relativement statiques (en dehors du moment où on
installe des logiciels). Et /tmp ne contient rien qu'on ne puisse
perdre. On peut même le monter sur /dev/shm (dans ce cas il vaut
peut-être mieux augmenter la taille de swap). Journaliser ces partitions
me paraît peu utile et même pénalisant pour la performance.
Donc, je dirais
/ /var et /home en ext3 (ou autre système journalisé).
/usr /usr/src et /tmp en ext2
Qu'en pensez vous?
Je me pose justement la question des systèmes de fichiers à utiliser. /usr et /usr/src sont relativement statiques (en dehors du moment où on installe des logiciels). Et /tmp ne contient rien qu'on ne puisse perdre. On peut même le monter sur /dev/shm (dans ce cas il vaut peut-être mieux augmenter la taille de swap). Journaliser ces partitions me paraît peu utile et même pénalisant pour la performance. Donc, je dirais / /var et /home en ext3 (ou autre système journalisé). /usr /usr/src et /tmp en ext2 Qu'en pensez vous?
Thomas Nemeth
Le mar 10 fév 2004 à 20:32, Cem a tapoté : | Le 10-02-2004, Daniel Déchelotte | a écrit : | > | > Tout en ext3 "naturellement". | [...] | Donc, je dirais | / /var et /home en ext3 (ou autre système journalisé). | /usr /usr/src et /tmp en ext2 | Qu'en pensez vous?
Moui. Note que la différence de perfs entre ext2 et ext3 est minime. Dans ce cas ce n'est intéressant que si /usr est monté en RO. Les autres c'est vrai qu'on s'en fout un peu.
De plus, si tu installes un serveur de mail et de news, qui utilisent un grand nombre de petits fichiers, il sera aussi nécessaire d'avoir un système de fichier adapté pour ce cas-là (et sur des partitions idoines : /var/mail et /var/spool/news). Un truc genre ReiserFS est intéressant si je me souviens bien des comparatifs que j'avais lu à l'époque de l'arrivée des FS journalisés dans le noyau...
Thomas -- JK:Y a-t-il un mot français pour tamagotchi (cette petite bête électronique) ? JR:J'ai en préparation un cathogauchi pour PC. Dès qu'il sera prêt je le poste. -+- in: Guide du Cabaliste Usenet - L'écran catholique de la Cabale -+-
Le mar 10 fév 2004 à 20:32, Cem a tapoté :
| Le 10-02-2004, Daniel Déchelotte <maitre_yodan@fr.club-internet.invalid>
| a écrit :
| >
| > Tout en ext3 "naturellement".
|
[...]
| Donc, je dirais
| / /var et /home en ext3 (ou autre système journalisé).
| /usr /usr/src et /tmp en ext2
| Qu'en pensez vous?
Moui.
Note que la différence de perfs entre ext2 et ext3 est minime. Dans
ce cas ce n'est intéressant que si /usr est monté en RO. Les autres
c'est vrai qu'on s'en fout un peu.
De plus, si tu installes un serveur de mail et de news, qui
utilisent un grand nombre de petits fichiers, il sera aussi
nécessaire d'avoir un système de fichier adapté pour ce cas-là
(et sur des partitions idoines : /var/mail et /var/spool/news).
Un truc genre ReiserFS est intéressant si je me souviens bien
des comparatifs que j'avais lu à l'époque de l'arrivée des FS
journalisés dans le noyau...
Thomas
--
JK:Y a-t-il un mot français pour tamagotchi (cette petite bête électronique) ?
JR:J'ai en préparation un cathogauchi pour PC. Dès qu'il sera prêt je le poste.
-+- in: Guide du Cabaliste Usenet - L'écran catholique de la Cabale -+-
Le mar 10 fév 2004 à 20:32, Cem a tapoté : | Le 10-02-2004, Daniel Déchelotte | a écrit : | > | > Tout en ext3 "naturellement". | [...] | Donc, je dirais | / /var et /home en ext3 (ou autre système journalisé). | /usr /usr/src et /tmp en ext2 | Qu'en pensez vous?
Moui. Note que la différence de perfs entre ext2 et ext3 est minime. Dans ce cas ce n'est intéressant que si /usr est monté en RO. Les autres c'est vrai qu'on s'en fout un peu.
De plus, si tu installes un serveur de mail et de news, qui utilisent un grand nombre de petits fichiers, il sera aussi nécessaire d'avoir un système de fichier adapté pour ce cas-là (et sur des partitions idoines : /var/mail et /var/spool/news). Un truc genre ReiserFS est intéressant si je me souviens bien des comparatifs que j'avais lu à l'époque de l'arrivée des FS journalisés dans le noyau...
Thomas -- JK:Y a-t-il un mot français pour tamagotchi (cette petite bête électronique) ? JR:J'ai en préparation un cathogauchi pour PC. Dès qu'il sera prêt je le poste. -+- in: Guide du Cabaliste Usenet - L'écran catholique de la Cabale -+-
TiChou
Dans l'article news:, Daniel Déchelotte écrivait :
Et ne sois pas effraye d'etre coince par une partition pleine. Si /usr est pleine, je fais un lien symbolique /usr/local/openoffice -> /home/openoffice et le probleme est regle.
C'est beaucoup plus souple qu'en FAT, ou si C: est plein, D: est vide, mais que le programme *veut* s'installer sur C:, t'es dans la mouise.
Oui, mais quelle idée aussi d'utiliser le système de fichier FAT. En NTFS on est loin de toutes ses limitations. L'utilisation des commandes fsutil.exe, linkd.exe ou mountvol.exe permet de la même manière que sous Unix de créer des liens hardware sur des fichiers, des répertoires et de monter des disques sur n'importe quel point de montage. On peut alors très facilement déplacer le contenu du dossier "c:Program Files" sur une autre volume, créer un point de jonction entre ce volume et le dossier "c:Program Files" laissant alors aux programmes accéder de manière transparente à ce dossier.
-- TiChou
Dans l'article
news:20040210132003.713d9e66.maitre_yodan@fr.club-internet.invalid,
Daniel Déchelotte <maitre_yodan@fr.club-internet.invalid> écrivait :
Et ne sois pas effraye d'etre coince par une partition pleine. Si /usr
est pleine, je fais un lien symbolique /usr/local/openoffice ->
/home/openoffice et le probleme est regle.
C'est beaucoup plus souple
qu'en FAT, ou si C: est plein, D: est vide, mais que le programme
*veut* s'installer sur C:, t'es dans la mouise.
Oui, mais quelle idée aussi d'utiliser le système de fichier FAT.
En NTFS on est loin de toutes ses limitations. L'utilisation des commandes
fsutil.exe, linkd.exe ou mountvol.exe permet de la même manière que sous
Unix de créer des liens hardware sur des fichiers, des répertoires et de
monter des disques sur n'importe quel point de montage. On peut alors très
facilement déplacer le contenu du dossier "c:Program Files" sur une autre
volume, créer un point de jonction entre ce volume et le dossier "c:Program
Files" laissant alors aux programmes accéder de manière transparente à ce
dossier.
Dans l'article news:, Daniel Déchelotte écrivait :
Et ne sois pas effraye d'etre coince par une partition pleine. Si /usr est pleine, je fais un lien symbolique /usr/local/openoffice -> /home/openoffice et le probleme est regle.
C'est beaucoup plus souple qu'en FAT, ou si C: est plein, D: est vide, mais que le programme *veut* s'installer sur C:, t'es dans la mouise.
Oui, mais quelle idée aussi d'utiliser le système de fichier FAT. En NTFS on est loin de toutes ses limitations. L'utilisation des commandes fsutil.exe, linkd.exe ou mountvol.exe permet de la même manière que sous Unix de créer des liens hardware sur des fichiers, des répertoires et de monter des disques sur n'importe quel point de montage. On peut alors très facilement déplacer le contenu du dossier "c:Program Files" sur une autre volume, créer un point de jonction entre ce volume et le dossier "c:Program Files" laissant alors aux programmes accéder de manière transparente à ce dossier.
