Debian
Debian-France
Debian-Facile
Debian-fr.org
Forum-Debian.fr
Debian ?
Communautés
Vous n'êtes pas identifié(e).
Dernière modification par Frosch (21-01-2016 17:45:46)
Hors ligne
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
Est-ce que ça vous est déjà arrivé de remplir plus de 20 GiB sur une partition racine ?
non 
je n'arrive jamais à 15 G en ce qui me concerne ...
edit :
avec le /tmp sur une partition à part
Dernière modification par wlourf (21-01-2016 16:45:57)
Hors ligne
Dernière modification par Frosch (21-01-2016 16:47:55)
Hors ligne
Hors ligne
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
Dernière modification par raleur (21-01-2016 17:38:31)
Il vaut mieux montrer que raconter.
Hors ligne
Quel intérêt de mettre le /tmp à part, au fait ?
De pouvoir remonter la racine en lecture seule par exemple (mais alors
il faut aussi une partition séparée pour /var, car il y a toujours
des fichiers ouverts dans /var…).
Ce dit, séparé /var et /tmp a du sens, mais ce n'est pas le plus simple à partitionner…
Dans ce cas on a d'ailleurs intérêt à utiliser lvm, pour pouvoir éventuellement faire évoluer
les tailles des différentes partitions au fil du temps et de l'utilisation… mais c'est une autre histoire.
Si je regarde la somme des tailles de mon systèmes pour /, /usr, et /var, ça fait dans les 21Go…
J'ai aussi séparé /home, /tmp et /boot… c'est très partitionné, en lvm bien sûr 
Hors ligne
Pour mon travail oui, ça doit passer par /tmp, surtout les videos
On peut aussi définir la variable d'environnement TMP ou TMPDIR sur un autre répertoire
que /tmp… donc si des commandes utilisateurs demande vraiment beaucoup d'espace
en fichier temporaire, il suffit de définir TMP=/rep/d'/une/partition/qui/a/de/la/place,
avant de lancer ces commandes
Évidemment, encore faut-il que ces commandes soient bien écrites et prennent en compte
la variable d'environnement TMP…
Dernière modification par enicar (21-01-2016 17:46:21)
Hors ligne
Hors ligne
De pouvoir remonter la racine en lecture seule
Sauf cas particulier, je ne pense pas que le système puisse fonctionner normalement avec la racine en lecture seule. Souvent le contenu de /etc doit être accessible en écriture, comme /etc/resolv.conf qui est modifié par les gestionnaires de réseau ou les clients DHCP, ou les fichiers de nommage persistant d'udev créés dans /etc/rules.d. Certes on pourrait déplacer ces fichiers ailleurs comme dans /var ou /run, mais il faut s'assurer que cela ne causera pas d'effet de bord (ex : besoin du fichier avant que son emplacement soit monté).
Par contre /usr peut être la plupart du temps monté en lecture seule (il n'a besoin d'être remonté en lecture-écriture que lors de l'installation, mise à jour ou suppression de paquets), c'est une bonne raison de le séparer de la racine.
Dernière modification par raleur (21-01-2016 18:29:25)
Il vaut mieux montrer que raconter.
Hors ligne
Sauf cas particulier, je ne pense pas que le système puisse fonctionner normalement avec la racine en lecture seule. Souvent le contenu de /etc doit être accessible en écriture, comme /etc/resolv.conf qui est modifié par les gestionnaires de réseau ou les clients DHCP, ou les fichiers de nommage persistant d'udev créés dans /etc/rules.d.
Moi, je parle d'une situation exceptionnelle, pas d'une utilisation en continue avec la racine montée en lecture seule.
Et ça m'est déjà arrivé de devoir monter la racine en lecture seule, et quand c'est possible, ça peut être très pratique.
Hors ligne
Hors ligne