Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

mais ou est passee la place manquante ?

25 réponses
Avatar
hamster
Salut a tous.

Je suis en train d'installer debian sur un ordi qui avait précedamment
windows 7. Avant d'installer j'ai fait un tour dans windows pour voir
les données que j'allais devoir récupérér. Il y avait une partition C:
avec le système et quelques données, sur laquelle il restait 5 Go de
libre. Le système prenant environ 50 Go, je me suis dit que j'allais
gagner de la place. Il y avait aussi une partition D: pleine de données
raz la gueule.

J'ai installé en faisant une swap de 4 Go, une partition root de 20 Go
et une partition /home a laquelle j'ai donné tout le reste de la place.

Bilan : 5 Go de libre + 50 Go de windows - 4 Go de swap - 20 Go de
debian, je pensais qu'une fois le /home rempli toutes les donnés il y
resterait une trentaine de Go de libre.

Et c'est bien ce que me dit gparted :
/dev/sda3 ext4 /home taille 572,11 Gio utilisé 541,36 Gio inutilisé
30,75 Gio

Par contre j'ai des messages d'alerte "attention la partition /home n'a
plus que 2,2 Go d'espace libre" et c'est aussi ce que me dit df -h  :
/dev/sda3   ext4   taille 563G   utilisé 532G   dispo 2,2G 100% /home

Du coup je comprend pas ou sont passés les 28 Go manquants. Ca fait
raler que les memes donnés prennent plus de place sur du ext4 que sur du
ntfs…

Merci donc pour vos lumières.

10 réponses

1 2 3
Avatar
hamster
Le 03/04/2019 à 17:44, Eric Degenetais a écrit :
J'ai installé en faisant une swap de 4 Go, une partition root de 20
 Go
et une partition /home a laquelle j'ai donné tout le reste de la
place.
Bilan : 5 Go de libre + 50 Go de windows - 4 Go de swap - 20 Go de
debian, je pensais qu'une fois le /home rempli toutes les donnés il y
resterait une trentaine de Go de libre.

N'y a t'il pas de l'espace réservé à root ?

comme dit plus haut, il y a une partoche root de 20 Go.
Avatar
Pascal Hambourg
Le 03/04/2019 à 19:44, Eric Degenetais a écrit :
Je parlais d'espace réservé au *compte* root. J'avais cru comprendre qu'une
partie de l'espace sur chaque partition est réservé à root pour qu'il
puisse travailler même sur une partition saturée. J'ai pu mal comprendre...

Non, tu as bien compris. Par défaut un système de fichiers ext* réserve
5% de l'espace à son utilisateur créateur, c'est-à-dire root la plupart
du temps. Concrètement, cela signifie que quand l'espace utilisé atteint
95%, les autres utilisateurs ne peuvent plus allouer d'espace.
La subtilité est que la quantité d'espace libre rapportée en tient compte.
/dev/sda3 ext4 taille 563G utilisé 532G dispo 2,2G 100% /home

5% de 563 Go, ça fait 28 Go.
563 - 532 - 2 = 29 Go on retombe à peu près sur nos pattes.
Si on considère qu'une telle réservation n'a pas lieu d'être pour /home
(ce qui est une position parfaitement valable puisque root n'est pas
censé avoir besoin d'écrire dans /home), alors on peut la modifier avec
tune2fs.
Avatar
hamster
Le 03/04/2019 à 19:57, Pascal Hambourg a écrit :
Le 03/04/2019 à 19:44, Eric Degenetais a écrit :
Je parlais d'espace réservé au *compte* root. J'avais cru comprendre
qu'une
partie de l'espace sur chaque partition est réservé à root pour qu'il
puisse travailler même sur une partition saturée. J'ai pu mal
comprendre...

Non, tu as bien compris. Par défaut un système de fichiers ext*
réserve 5% de l'espace à son utilisateur créateur, c'est-à-dire root
la plupart du temps. Concrètement, cela signifie que quand l'espace
utilisé atteint 95%, les autres utilisateurs ne peuvent plus allouer
d'espace.
La subtilité est que la quantité d'espace libre rapportée en tient compte.

Ce qui est pas plus mal vu que c'est de la place qui n'est pas
disponible pour les simples utilisateurs.
/dev/sda3   ext4   taille 563G   utilisé 532G   dispo 2,2G 100% /home
5% de 563 Go, ça fait 28 Go.
563 - 532 - 2 = 29 Go on retombe à peu près sur nos pattes.
Si on considère qu'une telle réservation n'a pas lieu d'être pour
/home (ce qui est une position parfaitement valable puisque root n'est
pas censé avoir besoin d'écrire dans /home), alors on peut la modifier
avec tune2fs.

Waouh, c'est bien ca. Merci beaucoup. Dorénavant je mettrai
systématiquement un coup de tune2fs -m 0 /dev/sdax sur la partoche /home.
Avatar
Pascal Hambourg
Le 04/04/2019 à 00:41, hamster a écrit :
Le 03/04/2019 à 19:57, Pascal Hambourg a écrit :
Non, tu as bien compris. Par défaut un système de fichiers ext*
réserve 5% de l'espace à son utilisateur créateur, c'est-à-dire root
la plupart du temps. Concrètement, cela signifie que quand l'espace
utilisé atteint 95%, les autres utilisateurs ne peuvent plus allouer
d'espace.


(...)
Si on considère qu'une telle réservation n'a pas lieu d'être pour
/home (ce qui est une position parfaitement valable puisque root n'est
pas censé avoir besoin d'écrire dans /home), alors on peut la modifier
avec tune2fs.

Waouh, c'est bien ca. Merci beaucoup. Dorénavant je mettrai
systématiquement un coup de tune2fs -m 0 /dev/sdax sur la partoche /home.

Partman, le programme pour partitionner les disques de l'installateur
Debian, permet d'ajuster le pourcentage de blocs réservés lors de
l'initialisation du système de fichiers.
Avatar
hamster
Le 04/04/2019 à 19:58, Pascal Hambourg a écrit :
Waouh, c'est bien ca. Merci beaucoup. Dorénavant je mettrai >> systématiquement un coup de tune2fs -m 0 /dev/sdax sur la partoche >>


/home. > > Partman, le programme pour partitionner les disques de
l'installateur > Debian, permet d'ajuster le pourcentage de blocs
réservés lors de > l'initialisation du système de fichiers.
Oui, j'y ai pensé quand vous m'en avez parlé. Mais vu qu'avant je ne
savais meme pas qu'il y avait des blocs réservés… je ne savais pas non
plus ce que cette option voulait dire.
Du coup j'ai fait un script pour corriger ca sur les ordis ou j'ai déjà
installé :
#!/bin/bash
homeUUID=$(grep "/home" /etc/fstab | grep -v "#" | cut -d"=" -f2 | cut
-d" " -f1);
homedevice=$(ls -l /dev/disk/by-uuid/ | grep $homeUUID | cut -d"/" -f3);
tune2fs -m 0 /dev/$homedevice;
Vu que je suis assez débutant en scripts, je veux bien le regard de
votre sagacité dessus.
Avatar
hamster
Le 04/04/2019 à 20:30, ajh-valmer a écrit :
On Thursday 04 April 2019 19:58:05 Pascal Hambourg wrote:
Partman, le programme pour partitionner les disques de l'installateur
Debian, permet d'ajuster le pourcentage de blocs réservés lors de
l'initialisation du système de fichiers.

gparted aussi le fait très bien.
Avant d'installer les systèmes, je partitionne à partir
d'une slitaz live avec gparted (mode graphique très facile).
Après, je copie Debian à partir d'un de mes 3 ordinateurs,
et j'adapte fstab, toujours sous slitaz et grub avec Super Grub Disk .
Reboot, et je me retrouve avec un système Debian complet prêt à l'emploi.

Je fais a peu près pareil, sauf que j'utilise plutot SystemRescueCD. Par
contre pour régler le pourcentage de blocs réservés dans gparted, j'ai
pas trouvé comment on fait. C'est ou qu'on clique ?
Avatar
=c3
hamster, au 2019-04-04 :
#!/bin/bash
homeUUID=$(grep "/home" /etc/fstab | grep -v "#" | cut -d"=" -f2 | cut
-d" " -f1);
homedevice=$(ls -l /dev/disk/by-uuid/ | grep $homeUUID | cut -d"/" -f3);
tune2fs -m 0 /dev/$homedevice;
Vu que je suis assez débutant en scripts, je veux bien le regard de
votre sagacité dessus.

Bonjour,
Vous l'avez demandé ; vous l'aurez. :)
Avant toute chose, il est préférable, quand une commande renvoie
un code d'erreur, d'arrêter le script aussitôt, ce que ne fait
pas bash par défaut, à moins de lui passer l'option `-e`. Il
suffit d'ajouter la commande suivant pour corriger cela :
set -e
Ensuite, j'aurais un peu ventilé pour éclaircir le propos, par
exemple comme suit :
homeUUID=$(
grep "/home" /etc/fstab
| grep -v "#"
| cut -d"=" -f2
| cut -d" " -f1
);
Cette manière de présenter le script est très aérée, et me
semble très lisible. La substitution de commande et le
pipelining ressortent assez bien. Mais comme il s'agit de
questions de style, peut-être que vous aurez des goûts
différents.
Ce n'est pas grand chose en soi, mais le saut de ligne permet de
séparer les commandes. Le ';' n'est alors pas nécessaire, à
moins que vous préfériez ne pas perdre d'habitudes issue du C :
homeUUID=$(
grep "/home" /etc/fstab
| grep -v "#"
| cut -d"=" -f2
| cut -d" " -f1
)
Dans ce genre d'affectation de variable, ça ne changera pas
grand chose ; mais d'ordinaire, je protège mes toutes mes
évaluations (symbole '$') avec des doubles quotes '"' comme
suit, quel que soit le contexte :
homeUUID="$(
grep "/home" /etc/fstab
| grep -v "#"
| cut -d"=" -f2
| cut -d" " -f1
)"
L'utilisation de l'opérateur d'évaluation '$()', à la place des
historiques backtick '`', est un bon réflexe : il a un ouvrant
et un fermant, et dispose de sont propre contexte pour les '"',
qui ne vont donc pas fermer les doubles quotes se trouvant en
dehors de l'évaluation, contrairement aux backticks :
echo "`grep "`du texte`" fichier`"
(Honnêtement, je ne suis même pas certain que la commande
ci-dessus fasse ce que je veux.) À comparer avec la commande
suivante franchement moins fouillis en caractères
d'échappement :
echo "$(grep "`du texte`" fichier)"
Pour l'évaluation du `homedevice`, en terme général, analyser la
sortie de la commande `ls` est dangereux, l'exemple typique
étant le traitement des fichiers avec des sauts de lignes
dedans. Dans le répertoire /dev/disk/by-uuid, ça ne devrait pas
poser problème, mais l'usage de `ls` dans un script est un
mauvais réflexe très (trop) courant. Une approche un peu plus
propre, à mon sens, pour résoudre le lien symbolique serait
d'utiliser `readlink` :
homedevice="$(
readlink -f "/dev/disk/by-uuid/$homeUUID"
)"
tune2fs -m 0 "$homedevice"
Ceci étant, quand on a des liens symboliques, c'est un peu
dommage de ne pas s'en servir, il est tout à fait possible
d'appliquer le `tune2fs` directement sur le disque par UUID. Le
système se charge de résoudre le lien symbolique vers le fichier
bloc correspondant pour l'opération :
homedevice="/dev/disk/by-uuid/$homeUUID"
À ce stade de la réflexion, le script ressemblerait donc à :
#!/bin/bash
set -e
homeUUID="$(
grep "/home" /etc/fstab
| grep -v "#"
| cut -d"=" -f2
| cut -d" " -f1
)"
homedevice="/dev/disk/by-uuid/$homeUUID"
tune2fs -m 0 "$homedevice"
Mais finalement, peut-être qu'on pourrait directement utiliser
le fichier bloc stockant /home tel que rapporté par la commande
`df`, plutôt que d'aller voir dans le fichier fstab, si
d'aventure il devait ne pas être à jour ? (À moins bien sûr que
ce ne soit à dessein.)
#!/bin/bash
set -e
homedevice="$(
df /home
| grep -v '^Filesystem'
| cut -f1 -d' '
)"
tune2fs -m 0 "$homedevice"
Attention, si le /home n'est pas sur une partition séparée,
alors c'est la partition de / qui va se voir supprimer les blocs
réservés à root. Avec le premier script, si le /home n'est pas
dans le fstab, et que `set -e` est présent, alors le script
s'arrête.
Pour aller plus loin, l'Advanced Bash Scripting guide est pour
moi un incontournable :
http://www.tldp.org/LDP/abs/html/index.html
Il est également disponible en Français, même si j'ai quelque
difficultés avec la traduction :
https://abs.traduc.org/abs-5.0-fr/
Voilà, prenez ce qui vous semble intéressant. :)
Amicalement,
--
Étienne Mollier
Ligne de commande épique :
# tune2fs -m0 "$(df /home|sed -n '2s/^([^ t]+).*/1/p')"
Avatar
hamster
Le 04/04/2019 à 23:21, Étienne Mollier a écrit :
Vous l'avez demandé ; vous l'aurez. :)

Merci beaucoup. C'est exactement le genre de commentaires qui me
permettent de progresser.
Ensuite, j'aurais un peu ventilé pour éclaircir le propos, par
exemple comme suit :
[…]
Cette manière de présenter le script est très aérée, et me
semble très lisible.

Par contre il est moins facile de tester les commandes qu'on met dans le
script en les copiant/collant dans un terminal.
Ceci étant, quand on a des liens symboliques, c'est un peu
dommage de ne pas s'en servir, il est tout à fait possible
d'appliquer le `tune2fs` directement sur le disque par UUID. Le
système se charge de résoudre le lien symbolique vers le fichier
bloc correspondant pour l'opération :
homedevice="/dev/disk/by-uuid/$homeUUID"

HAHAHA !
En effet, celle la elle est belle…
Mais finalement, peut-être qu'on pourrait directement utiliser
le fichier bloc stockant /home tel que rapporté par la commande
`df`, plutôt que d'aller voir dans le fichier fstab, si
d'aventure il devait ne pas être à jour ? (À moins bien sûr que
ce ne soit à dessein.)
#!/bin/bash
set -e
homedevice="$(
df /home
| grep -v '^Filesystem'
| cut -f1 -d' '
)"
tune2fs -m 0 "$homedevice"
Attention, si le /home n'est pas sur une partition séparée,
alors c'est la partition de / qui va se voir supprimer les blocs
réservés à root. Avec le premier script, si le /home n'est pas
dans le fstab, et que `set -e` est présent, alors le script
s'arrête.

Il y a en effet un problème de savoir quelle est la référence a
consulter. Je n'avais pas songé a l'éventualité que le montage fait
selon le fstab au démarrage puisse etre changé ensuite. D'un autre coté
utiliser la sortie de df risque de faire agir sur / comme tu l'a si bien
dit. Peut-etre la bonne référence est-elle le fichier /etc/mtab ?
#!/bin/bash
set -e
homedevice="$(
grep "/home" /etc/mtab
| cut -d" " -f1
)"
tune2fs -m 0 "$homedevice"
Pour aller plus loin, l'Advanced Bash Scripting guide est pour
moi un incontournable :
http://www.tldp.org/LDP/abs/html/index.html

Je note le lien. J'ai déjà fait des recherches de tutos pour faire des
scripts shell mais comme souvent je me suis perdu dans la profusion.
Trop de tutos tuent les tutos et les liens vers les références de
qualité deviennent un bien précieux.
Avatar
Pascal Hambourg
Le 04/04/2019 à 23:21, Étienne Mollier a écrit :
hamster, au 2019-04-04 :
#!/bin/bash
homeUUID=$(grep "/home" /etc/fstab | grep -v "#" | cut -d"=" -f2 | cut
-d" " -f1);
homedevice=$(ls -l /dev/disk/by-uuid/ | grep $homeUUID | cut -d"/" -f3);
tune2fs -m 0 /dev/$homedevice;


(...)
Ceci étant, quand on a des liens symboliques, c'est un peu
dommage de ne pas s'en servir, il est tout à fait possible
d'appliquer le `tune2fs` directement sur le disque par UUID. Le
système se charge de résoudre le lien symbolique vers le fichier
bloc correspondant pour l'opération :
homedevice="/dev/disk/by-uuid/$homeUUID"

Encore plus simple : comme mount, tune2fs accepte directement la syntaxe
UUID=<uuid> ou LABEL=<uuid> à la place du nom de périphérique. On ne lit
pas assez attentivement les pages de manuel.
Mais attention :
1) Vérifier que le système de fichiers est ext?, sinon la commande
tune2fs ne fonctionnera pas.
2) L'identification du système de fichiers à monter sur /home ne se fait
pas forcément par UUID. Ou bien si c'est un volume logique LVM ou un
volume chiffré, l'installateur utilise /dev/mapper/<volume>. Ou bien
l'administrateur a pu la remplacer par LABEL, PARTLABEL ou PARTUUID.
Mais finalement, peut-être qu'on pourrait directement utiliser
le fichier bloc stockant /home tel que rapporté par la commande
`df`, plutôt que d'aller voir dans le fichier fstab, si
d'aventure il devait ne pas être à jour ? (À moins bien sûr que
ce ne soit à dessein.)
#!/bin/bash
set -e
homedevice="$(
df /home
| grep -v '^Filesystem'
| cut -f1 -d' '
)"
tune2fs -m 0 "$homedevice"
Attention, si le /home n'est pas sur une partition séparée,

A tester auparavant avec mountpoint.
Avatar
Pascal Hambourg
Le 06/04/2019 à 10:40, Pascal Hambourg a écrit :
Encore plus simple : comme mount, tune2fs accepte directement la syntaxe
UUID=<uuid> ou LABEL=<uuid> à la place du nom de périphérique.

Il fallait bien sûr lire "LABEL=<label>". Attention aux espaces dans
l'étiquette qui sont échappés dans /etc/fstab, à éviter de préférence.
1 2 3