cerhu > linux.debian.user.french

hamster (03/04/2019, 16h20)
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.
Eric Degenetais (03/04/2019, 17h50)
Le mer. 3 avr. 2019 à 16:16, Bernard Schoenacker <
bernard.schoenacker> a écrit :

>> ----- Mail original -----

0
>> bonjour,

> serait il possible de vérifier les inodes ?
> documentation :
> [..]
> Les deux outils parlent visiblement en volume, donc ça ne me semble pas

pointer vers les inodes.
N'y a t'il pas de l'espace réservé à root ?

> merci
> slt
> bernard
>Cordialement

______________
Éric Dégenètais
Henix

[..]
[..]
hamster (03/04/2019, 18h30)
Le 03/04/2019 à 17:44, Eric Degenetais a écrit :
> 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.
Eric Degenetais (03/04/2019, 19h50)
Le mer. 3 avr. 2019 18:23, hamster <hamster> a écrit :

> Le 03/04/2019 à 17:44, Eric Degenetais a écrit :
> il y
> comme dit plus haut, il y a une partoche root de 20 Go.


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...

Éric Dégenètais
Pascal Hambourg (03/04/2019, 20h00)
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.
Cyrille Bollu (03/04/2019, 20h20)
Oui oui il y a 5% réservé à l?utilisateur root sur chaque partition.
[..]
hamster (04/04/2019, 00h50)
Le 03/04/2019 à 19:57, Pascal Hambourg a écrit :
> Le 03/04/2019 à 19:44, Eric Degenetais 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.
> 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.
Pascal Hambourg (04/04/2019, 20h00)
Le 04/04/2019 à 00:41, hamster a écrit :
> Le 03/04/2019 à 19:57, 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.
hamster (04/04/2019, 20h20)
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.
ajh-valmer (04/04/2019, 20h40)
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.

Essayez de faire ça avec Windows, niet !
Il faut tout réinstaller (maudit copyright).
hamster (04/04/2019, 22h00)
Le 04/04/2019 à 20:30, ajh-valmer a écrit :
> On Thursday 04 April 2019 19:58:05 Pascal Hambourg wrote:
> 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 ?
Étienne Mollier (04/04/2019, 23h30)
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 :

[..]

Il est également disponible en Français, même si j'ai quelque
difficultés avec la traduction :

[..]

Voilà, prenez ce qui vous semble intéressant. :)

Amicalement,
hamster (05/04/2019, 00h00)
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?

[..]
> | 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 :
> [..]


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.
Sébastien NOBILI (05/04/2019, 09h40)
Bonjour,

Le jeudi 04 avril 2019 à 23:50, hamster a écrit :
> Le 04/04/2019 à 23:21, Étienne Mollier a écrit :
> 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.


Je confirme la qualité de ce guide. Attention toutefois aux bashismes. Bash
fournit pas mal d?adaptations au standard (Bourne Shell) qui rendent
non-standard les scripts écrits pour lui et testés avec lui.

Pas de problème si on n?utilise que Bash, mais si un jour le shell change (par
exemple lorsque Debian est passé de Bash à Dash comme shell par défaut), alors
les scripts plantent (et en général avec des messages assez obscurs).

Pour éviter de se faire piéger (au choix) :
- éviter les bashismes (et faire du scripting standard)
- forcer l?utilisation de bash dans le shebang

Sébastien
Étienne Mollier (05/04/2019, 20h30)
Sébastien Nobili, au 2019-04-04 :
> Attention toutefois aux bashismes. Bash
> fournit pas mal d?adaptations au standard (Bourne Shell) qui rendent
> non-standard les scripts écrits pour lui et testés avec lui.
> Pas de problème si on n?utilise que Bash, mais si un jour le shell change (par
> exemple lorsque Debian est passé de Bash à Dash comme shell par défaut), alors
> les scripts plantent (et en général avec des messages assez obscurs).


Bonjour,

C'est une très bonne remarque, un certain nombre de fonctions
avancées de Bash ne peuvent pas être utilisée avec n'importe
quel shell. Le Dash a la vocation d'implémenter le standard, ni
plus, ni moins. Un script compatible Dash est donc censé
tourner de la même manière avec n'importe quel autre shell
compatible avec le Bourne Shell standard, du moins en théorie.

Quand un shell est appelé de manière implicite, typiquement pour
interpréter les recettes dans un Makefile, les bashismes peuvent
causer des dégâts. Et changer de shell dans ce genre de
contexte n'est pas toujours évident : je viens seulement de
découvrir l'existence de la variable SHELL dans make pour
changer d'interpréteur, par exemple?

Amicalement,

Discussions similaires
mais où est passée mon balcon?

Mais où est passée la 7° compagnie ?

Mais où est passée ma RAM ?

Où est passée la partie manquante ?


Fuseau horaire GMT +2. Il est actuellement 16h58. | Privacy Policy