Bon voila, je me suis - de nouveau - retrouvé avec la partition / qui
déborde (en fait l'autre fois c'était /var) là je suis en train de créer
une partition /usr (je sais c'est un abus de langage) et donc de déplacer
les fichiers. gparted m'a bien aidé et jusque là tout baigne.
Mon souci est le suivant : au lieu de déborder / va maintenant avoir 30
Go de libre : c'est plus qu'il n'en faut ! comment utiliser cette place :
shrinker / et créer une nouvelle partition ? Si vous avez une meilleure
idée, je prends !
Autre question :
Est-ce que mint live va bien me donner le bon uuid, celui que debian
reconnaitra ? l'uuid est-il inscrit quelque part dans la parttion ?
--
Quand dans un royaume il y a plus d'avantage a faire sa cour
qu'à faire son devoir, tout est perdu.
-+- Montesquieu -+-
Bonjour, Le 16/01/2019 à 11:49, Doug a écrit dans le message <q1n271$a19$ :
Pour /tmp, beaucoup de distributions se sont mises à monter un tmpfs (système de fichiers stockant les données en mémoire, swappable si nécessaire), et ça marche plutôt bien en général.
Ce qui m'a toujours semblé étonnant pour une utilisation en desktop lors de laquelle l'utilisateur peut-être amené à manier des données bien plus large que la quantité de mémoire disponible et donc à faire swapper le système. Je n'ai jamais pris le temps de faire des tests mais il me semble que certaines applications copient des données dans /tmp qui peuvent s'avérer assez volumineuses (probablement la plupart des logiciels d'édition d'images, audio et vidéo). J'imagine que l'intérêt est de gagner en performance lors de l'accès à ces données mais je ne suis pas persuadé que le jeu en vaille la chandelle d'autant plus si finalement les données finissent sur le disque en cas de swap.
Personnellement, vu ce que j'utilise comme mémoire : % free -m total used free shared buff/cache available Mem: 7909 1464 3560 70 2884 6076 Swap: 4387 0 4387 je n'ai aucun remord à avoir 4 Go disponible pour /tmp quand j'en ai besoin, par exemple pour compiler un programme, surtout qu'en temps normal ça ne coûte rien : % df -h /tmp Filesystem Size Used Avail Use% Mounted on tmpfs 3.9G 160K 3.9G 1% /tmp Il m'arrive d'avoir à augmenter /tmp à 7 Go pour pouvoir compiler des gros morceaux comme android-studio mais sinon ça ne me pose aucun problème depuis plusieurs années, je n'ai jamais constaté de swap (4 Go c'est quand même confortable).
Ce qui me gène c'est le fait que ce soit un choix par défaut et donc non réèllement consenti par l'utilisateur qui ne s'y connait pas nécessairement assez pour vérifier tout ça. Évidemment lorsque la configuration matérielle dispose de quantité de RAM qui frole le déraisonnable le problème ne se pose pas de la même manière que lorsqu'il s'agit d'un portable moyen de gamme de plus de 5 ans. Mon poste fixe dispose d'une quantité de RAM totalement extravagante mais pas mon portable, dont le poids des années commence à se faire sentir de manière régulière, qui dispose malgré tout de disques de tailles sérieuses. Créer par défaut un tmpfs sans tenir compte de la taille de la RAM et des disques présents ou de l'utilisation qui sera faite de la machine me semble un choix pauvre et c'est le reproche que je fais à la plupart des "grandes distributions" qui ont une tendance à appliquer des règles qui viennent d'on ne sait où de manière trop dogmatique à mon goût. XP+FU2 fcold
[désolé, je ne suis pas le FU2, je ne lis pas fcold] Il n'existe pas de règles qui marchent pour tout le monde donc j'imagine que ce qui a été choisi marche pour le plus grand nombre ; les autres devront faire par eux-mêmes ou en subir les conséquences (ça ressemble furieusement à la politique...). En tout cas, lorsque j'ai installé ma distribution en 2011 /tmp était déjà en tmpfs et comme je l'expliquais précédemment je n'ai jamais eu de problème avec sauf pour installer android-studio qui doit nécessiter un truc comme 5 ou 6 Go ; un coup de « mount -o remount,size=7G » et c'est reparti. PS : mon PC est un portable qui date de septembre 2011, j'ai du passer la RAM de 4 à 8 Go vers 2015 donc ce n'est pas ce que j'appelle une quantité de RAM déraisonnable. -- Benoit Izac
Bonjour,
Le 16/01/2019 à 11:49, Doug a écrit dans le message
<q1n271$a19$1@golgoth99.hacktruck.net> :
Pour /tmp, beaucoup de distributions se sont mises à monter un tmpfs
(système de fichiers stockant les données en mémoire, swappable si
nécessaire), et ça marche plutôt bien en général.
Ce qui m'a toujours semblé étonnant pour une utilisation en desktop lors
de laquelle l'utilisateur peut-être amené à manier des données bien plus
large que la quantité de mémoire disponible et donc à faire swapper le
système.
Je n'ai jamais pris le temps de faire des tests mais il me semble que
certaines applications copient des données dans /tmp qui peuvent
s'avérer assez volumineuses (probablement la plupart des logiciels
d'édition d'images, audio et vidéo).
J'imagine que l'intérêt est de gagner en performance lors de l'accès à
ces données mais je ne suis pas persuadé que le jeu en vaille la
chandelle d'autant plus si finalement les données finissent sur le
disque en cas de swap.
Personnellement, vu ce que j'utilise comme mémoire :
% free -m
total used free shared buff/cache available
Mem: 7909 1464 3560 70 2884 6076
Swap: 4387 0 4387
je n'ai aucun remord à avoir 4 Go disponible pour /tmp quand j'en ai
besoin, par exemple pour compiler un programme, surtout qu'en temps
normal ça ne coûte rien :
% df -h /tmp
Filesystem Size Used Avail Use% Mounted on
tmpfs 3.9G 160K 3.9G 1% /tmp
Il m'arrive d'avoir à augmenter /tmp à 7 Go pour pouvoir compiler des
gros morceaux comme android-studio mais sinon ça ne me pose aucun
problème depuis plusieurs années, je n'ai jamais constaté de swap (4 Go
c'est quand même confortable).
Ce qui me gène c'est le fait que ce soit un choix par défaut et donc non
réèllement consenti par l'utilisateur qui ne s'y connait pas
nécessairement assez pour vérifier tout ça.
Évidemment lorsque la configuration matérielle dispose de quantité de
RAM qui frole le déraisonnable le problème ne se pose pas de la même
manière que lorsqu'il s'agit d'un portable moyen de gamme de plus de 5
ans.
Mon poste fixe dispose d'une quantité de RAM totalement extravagante
mais pas mon portable, dont le poids des années commence à se faire
sentir de manière régulière, qui dispose malgré tout de disques de
tailles sérieuses.
Créer par défaut un tmpfs sans tenir compte de la taille de la RAM et
des disques présents ou de l'utilisation qui sera faite de la machine
me semble un choix pauvre et c'est le reproche que je fais à la
plupart des "grandes distributions" qui ont une tendance à appliquer
des règles qui viennent d'on ne sait où de manière trop dogmatique
à mon goût.
XP+FU2 fcold
[désolé, je ne suis pas le FU2, je ne lis pas fcold]
Il n'existe pas de règles qui marchent pour tout le monde donc j'imagine
que ce qui a été choisi marche pour le plus grand nombre ; les autres
devront faire par eux-mêmes ou en subir les conséquences (ça ressemble
furieusement à la politique...).
En tout cas, lorsque j'ai installé ma distribution en 2011 /tmp était
déjà en tmpfs et comme je l'expliquais précédemment je n'ai jamais eu de
problème avec sauf pour installer android-studio qui doit nécessiter un
truc comme 5 ou 6 Go ; un coup de « mount -o remount,size=7G » et
c'est reparti.
PS : mon PC est un portable qui date de septembre 2011, j'ai du passer
la RAM de 4 à 8 Go vers 2015 donc ce n'est pas ce que j'appelle une
quantité de RAM déraisonnable.
Bonjour, Le 16/01/2019 à 11:49, Doug a écrit dans le message <q1n271$a19$ :
Pour /tmp, beaucoup de distributions se sont mises à monter un tmpfs (système de fichiers stockant les données en mémoire, swappable si nécessaire), et ça marche plutôt bien en général.
Ce qui m'a toujours semblé étonnant pour une utilisation en desktop lors de laquelle l'utilisateur peut-être amené à manier des données bien plus large que la quantité de mémoire disponible et donc à faire swapper le système. Je n'ai jamais pris le temps de faire des tests mais il me semble que certaines applications copient des données dans /tmp qui peuvent s'avérer assez volumineuses (probablement la plupart des logiciels d'édition d'images, audio et vidéo). J'imagine que l'intérêt est de gagner en performance lors de l'accès à ces données mais je ne suis pas persuadé que le jeu en vaille la chandelle d'autant plus si finalement les données finissent sur le disque en cas de swap.
Personnellement, vu ce que j'utilise comme mémoire : % free -m total used free shared buff/cache available Mem: 7909 1464 3560 70 2884 6076 Swap: 4387 0 4387 je n'ai aucun remord à avoir 4 Go disponible pour /tmp quand j'en ai besoin, par exemple pour compiler un programme, surtout qu'en temps normal ça ne coûte rien : % df -h /tmp Filesystem Size Used Avail Use% Mounted on tmpfs 3.9G 160K 3.9G 1% /tmp Il m'arrive d'avoir à augmenter /tmp à 7 Go pour pouvoir compiler des gros morceaux comme android-studio mais sinon ça ne me pose aucun problème depuis plusieurs années, je n'ai jamais constaté de swap (4 Go c'est quand même confortable).
Ce qui me gène c'est le fait que ce soit un choix par défaut et donc non réèllement consenti par l'utilisateur qui ne s'y connait pas nécessairement assez pour vérifier tout ça. Évidemment lorsque la configuration matérielle dispose de quantité de RAM qui frole le déraisonnable le problème ne se pose pas de la même manière que lorsqu'il s'agit d'un portable moyen de gamme de plus de 5 ans. Mon poste fixe dispose d'une quantité de RAM totalement extravagante mais pas mon portable, dont le poids des années commence à se faire sentir de manière régulière, qui dispose malgré tout de disques de tailles sérieuses. Créer par défaut un tmpfs sans tenir compte de la taille de la RAM et des disques présents ou de l'utilisation qui sera faite de la machine me semble un choix pauvre et c'est le reproche que je fais à la plupart des "grandes distributions" qui ont une tendance à appliquer des règles qui viennent d'on ne sait où de manière trop dogmatique à mon goût. XP+FU2 fcold
[désolé, je ne suis pas le FU2, je ne lis pas fcold] Il n'existe pas de règles qui marchent pour tout le monde donc j'imagine que ce qui a été choisi marche pour le plus grand nombre ; les autres devront faire par eux-mêmes ou en subir les conséquences (ça ressemble furieusement à la politique...). En tout cas, lorsque j'ai installé ma distribution en 2011 /tmp était déjà en tmpfs et comme je l'expliquais précédemment je n'ai jamais eu de problème avec sauf pour installer android-studio qui doit nécessiter un truc comme 5 ou 6 Go ; un coup de « mount -o remount,size=7G » et c'est reparti. PS : mon PC est un portable qui date de septembre 2011, j'ai du passer la RAM de 4 à 8 Go vers 2015 donc ce n'est pas ce que j'appelle une quantité de RAM déraisonnable. -- Benoit Izac
Pascal Hambourg
Le 15/01/2019 à 20:03, Doug713705 a écrit :
Le 2019-01-14, Nicolas George nous expliquait :
Pour /tmp, beaucoup de distributions se sont mises à monter un tmpfs (système de fichiers stockant les données en mémoire, swappable si nécessaire), et ça marche plutôt bien en général.
Ce qui m'a toujours semblé étonnant pour une utilisation en desktop lors de laquelle l'utilisateur peut-être amené à manier des données bien plus large que la quantité de mémoire disponible et donc à faire swapper le système.
Je ne vois pas où est le problème. Même avec un /tmp classique, le noyau doit arbitrer l'allocation de la mémoire entre le cache de pages ("cache disque") et les processus. Or les tmpfs utilisent le cache de pages. Il faut juste dimensionner le swap en accord avec l'utilisation de /tmp. En gros l'espace disque qui serait alloué à /tmp doit être alloué au swap. L'avantage du tmpfs, c'est que les données ne sont jamais écrites sur disque si ce n'est pas nécessaire.
Le 15/01/2019 à 20:03, Doug713705 a écrit :
Le 2019-01-14, Nicolas George nous expliquait :
Pour /tmp, beaucoup de distributions se sont mises à monter un tmpfs
(système de fichiers stockant les données en mémoire, swappable si
nécessaire), et ça marche plutôt bien en général.
Ce qui m'a toujours semblé étonnant pour une utilisation en desktop lors
de laquelle l'utilisateur peut-être amené à manier des données bien plus
large que la quantité de mémoire disponible et donc à faire swapper le
système.
Je ne vois pas où est le problème. Même avec un /tmp classique, le noyau
doit arbitrer l'allocation de la mémoire entre le cache de pages ("cache
disque") et les processus. Or les tmpfs utilisent le cache de pages. Il
faut juste dimensionner le swap en accord avec l'utilisation de /tmp. En
gros l'espace disque qui serait alloué à /tmp doit être alloué au swap.
L'avantage du tmpfs, c'est que les données ne sont jamais écrites sur
disque si ce n'est pas nécessaire.
Pour /tmp, beaucoup de distributions se sont mises à monter un tmpfs (système de fichiers stockant les données en mémoire, swappable si nécessaire), et ça marche plutôt bien en général.
Ce qui m'a toujours semblé étonnant pour une utilisation en desktop lors de laquelle l'utilisateur peut-être amené à manier des données bien plus large que la quantité de mémoire disponible et donc à faire swapper le système.
Je ne vois pas où est le problème. Même avec un /tmp classique, le noyau doit arbitrer l'allocation de la mémoire entre le cache de pages ("cache disque") et les processus. Or les tmpfs utilisent le cache de pages. Il faut juste dimensionner le swap en accord avec l'utilisation de /tmp. En gros l'espace disque qui serait alloué à /tmp doit être alloué au swap. L'avantage du tmpfs, c'est que les données ne sont jamais écrites sur disque si ce n'est pas nécessaire.
Pascal Hambourg
Le 13/01/2019 à 20:14, Pascal en Trophy a écrit :
Le 13/01/2019 19:35, Pascal Hambourg a écrit :
Eviter que les utilisateurs,
Il existe une gestion de Quotas pour ça, il me semble, non ?
Il me semble que tous les systèmes de fichiers ne supportent pas les quotas.
les logs ou les caches divers bouffent tout l'espace disque.
Possible de gérer pas les quotas ?
Je soupçonne que root échappe aux quotas, donc sans effet si les processus qui écrivent les logs s'exécutent en root.
Choisir les types de systèmes de fichiers les plus adaptés au contenu.
Aurais-tu des exemples pour que je comprenne l'intérêt ?
Je n'ai pas vraiment creusé le sujet. Mais certains systèmes de fichiers sont plus adaptés au stockage de nombreux petits fichiers, d'autres aux gros fichiers, sont plus ou moins performants pour la création/suppression de nombreux fichiers, la gestion de nombreux fichiers dans un même répertoire...
Hormis le swap, celui-là, je le connais.
Le swap n'est pas un système de fichiers.
Monter les parties statiques de l'arborescence en lecture seule.
Ca, c'est une mesure de sécurité supplémentaire, non ? Genre, si jamais une vérole arrive à craquer le compte root, elle ne peut pas effacer de fichiers ?
Si une vérole passe root, elle peut tout faire, y compris remonter en lecture-écriture. C'est plus une précaution contre la corruption accidentelle.
Limiter l'étendue de la corruption d'un système de fichiers.
Ca arrive ?
Oui. fsck n'est pas lancé automatiquement au démarrage pour rien.
Autant je visualise bien des problèmes de disque dur (je ne compte plus le nombre que j'ai déposé à la déchetterie), autant je vois moins sur une partition. Je crois bien que je n'ai jamais eu ce genre de soucis.
Moi si. Pas forcément grave, mais qui nécessitait une intervention manuelle.
Simplifier les sauvegardes et la restauration.
Comme par exemple faire une copie "brute" (par dd ?) d'une partition sur un média de sauvegarde ?
Par exemple, mais pas seulement. Des programmes de copie, synchronisation ou sauvegarde ont une option pour ne pas franchir les limites des systèmes de fichiers. L'avantage est surtout à la restauration en cas de corruption irréparable du système de fichiers : on ne reformate et restaure que le système de fichiers endommagé.
Le 13/01/2019 à 20:14, Pascal en Trophy a écrit :
Le 13/01/2019 19:35, Pascal Hambourg a écrit :
Eviter que les utilisateurs,
Il existe une gestion de Quotas pour ça, il me semble, non ?
Il me semble que tous les systèmes de fichiers ne supportent pas les quotas.
les logs ou les caches divers bouffent tout l'espace disque.
Possible de gérer pas les quotas ?
Je soupçonne que root échappe aux quotas, donc sans effet si les
processus qui écrivent les logs s'exécutent en root.
Choisir les types de systèmes de fichiers les plus adaptés au contenu.
Aurais-tu des exemples pour que je comprenne l'intérêt ?
Je n'ai pas vraiment creusé le sujet. Mais certains systèmes de fichiers
sont plus adaptés au stockage de nombreux petits fichiers, d'autres aux
gros fichiers, sont plus ou moins performants pour la
création/suppression de nombreux fichiers, la gestion de nombreux
fichiers dans un même répertoire...
Hormis le swap, celui-là, je le connais.
Le swap n'est pas un système de fichiers.
Monter les parties statiques de l'arborescence en lecture seule.
Ca, c'est une mesure de sécurité supplémentaire, non ? Genre, si jamais
une vérole arrive à craquer le compte root, elle ne peut pas effacer de
fichiers ?
Si une vérole passe root, elle peut tout faire, y compris remonter en
lecture-écriture. C'est plus une précaution contre la corruption
accidentelle.
Limiter l'étendue de la corruption d'un système de fichiers.
Ca arrive ?
Oui. fsck n'est pas lancé automatiquement au démarrage pour rien.
Autant je visualise bien des problèmes de disque dur (je ne
compte plus le nombre que j'ai déposé à la déchetterie), autant je vois
moins sur une partition. Je crois bien que je n'ai jamais eu ce genre de
soucis.
Moi si. Pas forcément grave, mais qui nécessitait une intervention manuelle.
Simplifier les sauvegardes et la restauration.
Comme par exemple faire une copie "brute" (par dd ?) d'une partition sur
un média de sauvegarde ?
Par exemple, mais pas seulement. Des programmes de copie,
synchronisation ou sauvegarde ont une option pour ne pas franchir les
limites des systèmes de fichiers. L'avantage est surtout à la
restauration en cas de corruption irréparable du système de fichiers :
on ne reformate et restaure que le système de fichiers endommagé.
Il existe une gestion de Quotas pour ça, il me semble, non ?
Il me semble que tous les systèmes de fichiers ne supportent pas les quotas.
les logs ou les caches divers bouffent tout l'espace disque.
Possible de gérer pas les quotas ?
Je soupçonne que root échappe aux quotas, donc sans effet si les processus qui écrivent les logs s'exécutent en root.
Choisir les types de systèmes de fichiers les plus adaptés au contenu.
Aurais-tu des exemples pour que je comprenne l'intérêt ?
Je n'ai pas vraiment creusé le sujet. Mais certains systèmes de fichiers sont plus adaptés au stockage de nombreux petits fichiers, d'autres aux gros fichiers, sont plus ou moins performants pour la création/suppression de nombreux fichiers, la gestion de nombreux fichiers dans un même répertoire...
Hormis le swap, celui-là, je le connais.
Le swap n'est pas un système de fichiers.
Monter les parties statiques de l'arborescence en lecture seule.
Ca, c'est une mesure de sécurité supplémentaire, non ? Genre, si jamais une vérole arrive à craquer le compte root, elle ne peut pas effacer de fichiers ?
Si une vérole passe root, elle peut tout faire, y compris remonter en lecture-écriture. C'est plus une précaution contre la corruption accidentelle.
Limiter l'étendue de la corruption d'un système de fichiers.
Ca arrive ?
Oui. fsck n'est pas lancé automatiquement au démarrage pour rien.
Autant je visualise bien des problèmes de disque dur (je ne compte plus le nombre que j'ai déposé à la déchetterie), autant je vois moins sur une partition. Je crois bien que je n'ai jamais eu ce genre de soucis.
Moi si. Pas forcément grave, mais qui nécessitait une intervention manuelle.
Simplifier les sauvegardes et la restauration.
Comme par exemple faire une copie "brute" (par dd ?) d'une partition sur un média de sauvegarde ?
Par exemple, mais pas seulement. Des programmes de copie, synchronisation ou sauvegarde ont une option pour ne pas franchir les limites des systèmes de fichiers. L'avantage est surtout à la restauration en cas de corruption irréparable du système de fichiers : on ne reformate et restaure que le système de fichiers endommagé.
Pascal en Trophy
BONNE ANNEE !! Le 16/01/2019 23:10, Pascal Hambourg a écrit :
Comme par exemple faire une copie "brute" (par dd ?) d'une partition
sur un média de sauvegarde ?
Par exemple, mais pas seulement. Des programmes de copie, synchronisation ou sauvegarde ont une option pour ne pas franchir les limites des systèmes de fichiers. L'avantage est surtout à la restauration en cas de corruption irréparable du système de fichiers : on ne reformate et restaure que le système de fichiers endommagé.
Ok, merci, c'est plus clair maintenant. Pascal en Trophy
BONNE ANNEE !!
Le 16/01/2019 23:10, Pascal Hambourg a écrit :
>> Comme par exemple faire une copie "brute" (par dd ?) d'une partition
sur un média de sauvegarde ?
Par exemple, mais pas seulement. Des programmes de copie,
synchronisation ou sauvegarde ont une option pour ne pas franchir les
limites des systèmes de fichiers. L'avantage est surtout à la
restauration en cas de corruption irréparable du système de fichiers :
on ne reformate et restaure que le système de fichiers endommagé.
BONNE ANNEE !! Le 16/01/2019 23:10, Pascal Hambourg a écrit :
Comme par exemple faire une copie "brute" (par dd ?) d'une partition
sur un média de sauvegarde ?
Par exemple, mais pas seulement. Des programmes de copie, synchronisation ou sauvegarde ont une option pour ne pas franchir les limites des systèmes de fichiers. L'avantage est surtout à la restauration en cas de corruption irréparable du système de fichiers : on ne reformate et restaure que le système de fichiers endommagé.
Ok, merci, c'est plus clair maintenant. Pascal en Trophy
denis.paris
Le 16/01/2019 à 19:07, Doug713705 a écrit :
Le /tmp que tu vois ne serait t-il pas un montage lié (mount -o bind) du tmpfs ?
Non, car quand je reboote la machine sur un live OS comme clonezilla par exemple pour sauvegarder à froid la partition / il y a encore des fichiers quand je monte cette partition, et en général je fais le ménage à ce moment-là (avant de la démonter et de lancer clonezilla).
Le 16/01/2019 à 19:07, Doug713705 a écrit :
Le /tmp que tu vois ne serait t-il pas un montage lié (mount -o bind) du
tmpfs ?
Non, car quand je reboote la machine sur un live OS comme clonezilla par
exemple pour sauvegarder à froid la partition / il y a encore des
fichiers quand je monte cette partition, et en général je fais le ménage
à ce moment-là (avant de la démonter et de lancer clonezilla).
Le /tmp que tu vois ne serait t-il pas un montage lié (mount -o bind) du tmpfs ?
Non, car quand je reboote la machine sur un live OS comme clonezilla par exemple pour sauvegarder à froid la partition / il y a encore des fichiers quand je monte cette partition, et en général je fais le ménage à ce moment-là (avant de la démonter et de lancer clonezilla).
Jo Engo
Le Wed, 16 Jan 2019 10:49:05 +0000, Doug713705 a écrit :
Ce qui me gène c'est le fait que ce soit un choix par défaut
Ça ne l'est pas (du moins avec ubuntu) Ubuntu, (quasiment) out of the box : :~$ df -h /tmp Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur /dev/sda1 292G 135G 142G 49% / -- En général, l'esprit doit se plier aux conditions du savoir. Il doit créer en lui une structure correspondant à celle du savoir. -+- Gaston Bachelard
Le Wed, 16 Jan 2019 10:49:05 +0000, Doug713705 a écrit :
Ce qui me gène c'est le fait que ce soit un choix par défaut
Ça ne l'est pas (du moins avec ubuntu)
Ubuntu, (quasiment) out of the box :
abdallah@colibri:~$ df -h /tmp
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
/dev/sda1 292G 135G 142G 49% /
--
En général, l'esprit doit se plier aux conditions du savoir. Il doit
créer en lui une structure correspondant à celle du savoir.
-+- Gaston Bachelard
Le Wed, 16 Jan 2019 10:49:05 +0000, Doug713705 a écrit :
Ce qui me gène c'est le fait que ce soit un choix par défaut
Ça ne l'est pas (du moins avec ubuntu) Ubuntu, (quasiment) out of the box : :~$ df -h /tmp Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur /dev/sda1 292G 135G 142G 49% / -- En général, l'esprit doit se plier aux conditions du savoir. Il doit créer en lui une structure correspondant à celle du savoir. -+- Gaston Bachelard
denis.paris
Le 18/01/2019 à 11:17, Jo Engo a écrit :
Le Wed, 16 Jan 2019 10:49:05 +0000, Doug713705 a écrit :
Ce qui me gène c'est le fait que ce soit un choix par défaut
Ça ne l'est pas (du moins avec ubuntu) Ubuntu, (quasiment) out of the box : :~$ df -h /tmp Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur /dev/sda1 292G 135G 142G 49% /
Mais ça n'indique par la taille de /tmp, cette commande dit juste que /tmp est dans la même partition que / C'est peut-être du -hs que tu voulais faire?
Le 18/01/2019 à 11:17, Jo Engo a écrit :
Le Wed, 16 Jan 2019 10:49:05 +0000, Doug713705 a écrit :
Ce qui me gène c'est le fait que ce soit un choix par défaut
Ça ne l'est pas (du moins avec ubuntu)
Ubuntu, (quasiment) out of the box :
abdallah@colibri:~$ df -h /tmp
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
/dev/sda1 292G 135G 142G 49% /
Mais ça n'indique par la taille de /tmp, cette commande dit juste que
/tmp est dans la même partition que /
Le Wed, 16 Jan 2019 10:49:05 +0000, Doug713705 a écrit :
Ce qui me gène c'est le fait que ce soit un choix par défaut
Ça ne l'est pas (du moins avec ubuntu) Ubuntu, (quasiment) out of the box : :~$ df -h /tmp Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur /dev/sda1 292G 135G 142G 49% /
Mais ça n'indique par la taille de /tmp, cette commande dit juste que /tmp est dans la même partition que / C'est peut-être du -hs que tu voulais faire?
Michel Talon
Le 18/01/2019 à 13:36, denis.paris a écrit :
Mais ça n'indique par la taille de /tmp, cette commande dit juste que /tmp est dans la même partition que / C'est peut-être du -hs que tu voulais faire?
Cette commande t'indique qu'il y a 142 G utilisables pour des trucs dans /tmp. -- Michel Talon
Le 18/01/2019 à 13:36, denis.paris a écrit :
Mais ça n'indique par la taille de /tmp, cette commande dit juste que
/tmp est dans la même partition que /
C'est peut-être du -hs que tu voulais faire?
Cette commande t'indique qu'il y a 142 G utilisables pour des trucs dans
/tmp.
Mais ça n'indique par la taille de /tmp, cette commande dit juste que /tmp est dans la même partition que / C'est peut-être du -hs que tu voulais faire?
Cette commande t'indique qu'il y a 142 G utilisables pour des trucs dans /tmp. -- Michel Talon
denis.paris
Le 18/01/2019 à 15:12, Michel Talon a écrit :
Le 18/01/2019 à 13:36, denis.paris a écrit :
Mais ça n'indique par la taille de /tmp, cette commande dit juste que /tmp est dans la même partition que / C'est peut-être du -hs que tu voulais faire?
Cette commande t'indique qu'il y a 142 G utilisables pour des trucs dans /tmp.
OK, j'ai compris l'expression "out of the box" comme étant l'installation par défaut, qui ne met pas /tmp dans une partition séparée (et pire met /home sur la racine!) Pour /tmp cela semble être le cas de Doug parce que c'est la première (partition principale): :~$ df -h /tmp Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur /dev/sda1 292G 135G 142G 49% /
Le 18/01/2019 à 15:12, Michel Talon a écrit :
Le 18/01/2019 à 13:36, denis.paris a écrit :
Mais ça n'indique par la taille de /tmp, cette commande dit juste que
/tmp est dans la même partition que /
C'est peut-être du -hs que tu voulais faire?
Cette commande t'indique qu'il y a 142 G utilisables pour des trucs dans
/tmp.
OK, j'ai compris l'expression "out of the box" comme étant
l'installation par défaut, qui ne met pas /tmp dans une partition
séparée (et pire met /home sur la racine!) Pour /tmp cela semble être le
cas de Doug parce que c'est la première (partition principale):
abdallah@colibri:~$ df -h /tmp
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
/dev/sda1 292G 135G 142G 49% /
Mais ça n'indique par la taille de /tmp, cette commande dit juste que /tmp est dans la même partition que / C'est peut-être du -hs que tu voulais faire?
Cette commande t'indique qu'il y a 142 G utilisables pour des trucs dans /tmp.
OK, j'ai compris l'expression "out of the box" comme étant l'installation par défaut, qui ne met pas /tmp dans une partition séparée (et pire met /home sur la racine!) Pour /tmp cela semble être le cas de Doug parce que c'est la première (partition principale): :~$ df -h /tmp Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur /dev/sda1 292G 135G 142G 49% /
denis.paris
Le 18/01/2019 à 16:39, zeLittle a écrit :
Le Fri, 18 Jan 2019 16:05:15 +0100, denis.paris a écrit:
OK, j'ai compris l'expression "out of the box" comme étant l'installation par défaut, qui ne met pas /tmp dans une partition séparée (et pire met /home sur la racine!) Pour /tmp cela semble être le cas de Doug parce que c'est la première (partition principale): :~$ df -h /tmp Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur /dev/sda1 292G 135G 142G 49% /
Concernant Ubuntu, il faut d'abord utiliser une clé bootable (lUbuntu) en mode live sur le poste formaté (après sauvegarde des données home) pour le partitionner préalablement avec GParted comme voulu (de gauche à droite: une partition par répertoire racine à monter dessus - la première pour "/", puis celles que l'on veut - et le swap de 1024 octets au final), puis ensuite relancer la machine en bootant cette fois-ci sur un *.iso de la distrib. d'Ubuntu voulue, puis en sélectionnant lors de son installation une option du style "je veux faire autrement" (pas les autres options "installation minimaliste" ou "installation avec les programmes" de mémoire).
Je suis d'accord, c'est possible avec le CD d'installation mais les écrans sont assez mal foutus (en mode texte. Notamment sur une machine virtuelle, les boutons de commande en bas de la page ne sont pas accessibles, ils faut les valider en aveugle en comptant le nombre de pressions sur la touche TAB. Remarque: le CD LIVE permet aussi l'installation en mode graphique, donc pas besoin de changer de support.
Le 18/01/2019 à 16:39, zeLittle a écrit :
Le Fri, 18 Jan 2019 16:05:15 +0100, denis.paris
<denis.paris@free.invalid> a écrit:
OK, j'ai compris l'expression "out of the box" comme étant
l'installation par défaut, qui ne met pas /tmp dans une partition
séparée (et pire met /home sur la racine!) Pour /tmp cela semble être
le cas de Doug parce que c'est la première (partition principale):
abdallah@colibri:~$ df -h /tmp
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
/dev/sda1 292G 135G 142G 49% /
Concernant Ubuntu, il faut d'abord utiliser une clé bootable (lUbuntu)
en mode live sur le poste formaté (après sauvegarde des données home)
pour le partitionner préalablement avec GParted comme voulu (de gauche à
droite: une partition par répertoire racine à monter dessus - la
première pour "/", puis celles que l'on veut - et le swap de 1024 octets
au final), puis ensuite relancer la machine en bootant cette fois-ci sur
un *.iso de la distrib. d'Ubuntu voulue, puis en sélectionnant lors de
son installation une option du style "je veux faire autrement" (pas les
autres options "installation minimaliste" ou "installation avec les
programmes" de mémoire).
Je suis d'accord, c'est possible avec le CD d'installation mais les
écrans sont assez mal foutus (en mode texte. Notamment sur une machine
virtuelle, les boutons de commande en bas de la page ne sont pas
accessibles, ils faut les valider en aveugle en comptant le nombre de
pressions sur la touche TAB.
Remarque: le CD LIVE permet aussi l'installation en mode graphique, donc
pas besoin de changer de support.
Le Fri, 18 Jan 2019 16:05:15 +0100, denis.paris a écrit:
OK, j'ai compris l'expression "out of the box" comme étant l'installation par défaut, qui ne met pas /tmp dans une partition séparée (et pire met /home sur la racine!) Pour /tmp cela semble être le cas de Doug parce que c'est la première (partition principale): :~$ df -h /tmp Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur /dev/sda1 292G 135G 142G 49% /
Concernant Ubuntu, il faut d'abord utiliser une clé bootable (lUbuntu) en mode live sur le poste formaté (après sauvegarde des données home) pour le partitionner préalablement avec GParted comme voulu (de gauche à droite: une partition par répertoire racine à monter dessus - la première pour "/", puis celles que l'on veut - et le swap de 1024 octets au final), puis ensuite relancer la machine en bootant cette fois-ci sur un *.iso de la distrib. d'Ubuntu voulue, puis en sélectionnant lors de son installation une option du style "je veux faire autrement" (pas les autres options "installation minimaliste" ou "installation avec les programmes" de mémoire).
Je suis d'accord, c'est possible avec le CD d'installation mais les écrans sont assez mal foutus (en mode texte. Notamment sur une machine virtuelle, les boutons de commande en bas de la page ne sont pas accessibles, ils faut les valider en aveugle en comptant le nombre de pressions sur la touche TAB. Remarque: le CD LIVE permet aussi l'installation en mode graphique, donc pas besoin de changer de support.
