df : taille variable de la partition

Version imprimable

Bonjour,

il y a trois semaines environ j'ai utilisé cette ligne de commande (https://www.developpez.net/forums/d2.../) pour remonter des infos sur mes disques :

Code:

while read ligne; do echo "$ligne"; done < <(df -B1 -x tmpfs -x devtmpfs --output=source,fstype,itotal,iused,iavail,ipcent,size,used,avail,pcent,file,target)

Ça m'a donné des choses comme ça :
Code:

1 2 3 4 Sys. de fichiers Type Inœuds IUtil. ILibre IUti% blocs de 1B Utilisé Dispo Uti% Fichier Monté sur /dev/sda1 ext4 12804096 383963 12420133 3% 205349208064 36280119296 158566551552 19% - / /dev/sdb1 ext4 109297664 165583 109132081 1% 1761511104512 830367956992 841592242176 50% - /data /dev/sdc1 ext4 109297664 286644 109011020 1% 1761511104512 832030683136 839929516032 50% - /dbck
Content, le monsieur, :ccool:

Aujourd'hui je lance la même commande (par copier/coller depuis un fichier texte de notes) :
Code:

1 2 3 4 Sys. de fichiers Type Inœuds IUtil. ILibre IUti% blocs de 1B Utilisé Dispo Uti% Fichier Monté sur /dev/sda1 ext4 12804096 481819 12322277 4% 205286293504 46168965120 148614791168 24% - / /dev/sdb1 ext4 109297664 165829 109131835 1% 1761439584256 831196864512 840691814400 50% - /data /dev/sdc1 ext4 109297664 296762 109000902 1% 1761439584256 833015537664 838873141248 50% - /dbck
et je vous invite à comparer les valeurs de la colonne blocs de 1B :
Code:

1 2 3 4 partition | /dev/sda1 | /dev/sdb1 | /dev/sdc1 il y a 3 sem. | 205349208064 | 1761511104512 | 1761511104512 aujourdhui | 205286293504 | 1761439584256 | 1761439584256 diff. en blocs | 62914560 | 71520256 | 71520256
Qu'en conclure ? Que mes 3 disques (les 2 derniers sont strictement identiques et partitionnés de la même manière) ont perdu des blocs de 1 B ? Pourtant le nombre d'inodes n'a pas bougé, lui.
Ou alors ce sont les infos système qui ont évolué dans leurs calculs, suite à une mise à jour ?
J'ai regardé les dates de /usr/include/x86_64-linux-gnu/bits/statvfs.h et de /usr/include/x86_64-linux-gnu/sys/statvfs.h, ça remonte à 2020, :koi:
(je parle de ce statvfs.h car je l'utilise dans un petit prog en C dérivé de man statfs, et j'y ai le même comportement étrange…)

Une idée pour expliquer cette perte de 62914560 + 71520256*2 = 214560768 blocs de 1B ?
Merci,

27/08/2022, 12h21
Sve@r
Bonjour

Citation:

Envoyé par Jipété

Une idée pour expliquer cette perte de blocs de 1B ?

Quand tu as posté, je suis venu voir. Sans réponse, je n'ai rien dit, espérant qu'un autre intervenant en saurait plus. Mais aujourd'hui, 15 jours plus tard, toujours rien.

Alors je me suis livré à un petit calcul pour essayer de comprendre ce que ce "bloc1B" pouvait représenter
Pour /dev/sda1, tu as 36 280 119 296 utilisé, et 158 566 551 552 en dispo. Le total fait 194 846 670 848. Déjà cela ne matche pas la valeur "1B" de 205 349 208 064 (il s'en faut de 10 502 537 216 soit 5,1145%, merci à Excel soit dit en passant).
Si je regarde ce qui est utilisé (36...) par rapport au total (194...) je tombe sur 18,6198% (soit arrondi à 19% ce qui correspond à ce qui est affiché).
Si maintenant je fais le même calcul par rapport aux blocs de 1B (donc 36... en pourcentage sur 205...) j'obtiens 17,6675% soit 18% en arrondi. Donc il me semble clair que le pourcentage est calculé sur la somme "occupé+libre" et non pas la valeur "1B" qui ne me semble pas pertinente.

Je prends maintenant ton même /dev/sda1 à 3 semaines plus tard. Accessoirement il convient de noter que la version Ubuntu a changé ces derniers temps. Elle est passé de 20.04 à 22.04 (as-tu changé pendant ces 3 semaines?)
Blocs utilisés 46 168 965 120 - Blocs libres 148 614 791 168 - Total 194 783 756 288 - Blocs 1B: 205 286 293 504 (différence 10 502 537 216 soit 5.1160%)
Pourcentage utilisés sur total (donc 46... sur 194...) = 23,7027% (ou 24% comme affiché) - Pourcentage utilisés sur 1B: 22,49 (ou 23%) - Donc là encore le pourcentage affiché semble être calculé sur le total et non pas sur cette valeur "1B"

Alors c'est quoi ce "blocs 1B" : pour moi, ça représente la taille totale du sd, avant création du FS. Car tu n'est certainement pas sans savoir que cette création réserve par défaut 5% pour qu'en cas de souci, le root puisse encore travailler à le réparer. Or les écarts "1B/total" sont tous très très proches de 5%.
D'ailleurs je fais un essai maintenant avec une machine virtuelle sur laquelle je crée un disque de 1Go et pour lequel je demande un pourcentage à 0% (option "-m0" de mkfs.ext4")
Puis je crée un fichier assez conséquant via dd if=/dev/zero of=zero count=1200000 ce qui crée un fichier de 614MB
Et au résultat: occupés 614 424 576, libres 405 229 568, total 1 019 654 144 soit 60,2581% (arrondi à 60% tandis que "df" me donne 61%.. peut-être l'arrondi est-il systématiquement supérieur :?).
Mais blocs 1B =1 036 431 360 (ce qui est assez proche de 1Go) et la différence entre 1B et total est de 16 777 216 soit 1,6187% (2% alors que j'avais demandé 0%...:?)

Refaisons un essai avec un pourcentage réservé à 28%... (mkfs.ext4 -m28 /dev/...) et un fichier identique de 614MB
Blocs occupés: 614 424 576, libres 104 878 080, total 719 302 656 (pourcentage occupé = 85.4195% et "df" donne 86% donc arrondi très probablement donné à l'unité supérieure).
Et blocs1B 1 036 431 360 (pareil), et différence entre 1B et total = 317 128 704 soit 30.5981% (30% assez proche de 28% demandés, oui je sais je "tords" un peu les chiffres pour les faire correspondre à mon hypothèse mais sinon je n'en ai pas d'autre...:oops:)

Ce que j'en conclus, c'est que cette valeur "blocs 1B" est la taille totale de la partition (je dis bien "partition" et non pas "filesystem"). Ensuite, le filesystem est créé, filesystem qui contient 4 parties
- la zone de boot (512 octets)
- le super bloc (taille variable mais toujours multiple parfait de 512)
- la table des inodes (qui est modulable à la création du FS)
- la zone de datas
Fatalement, la taille disponible (celle de la zone de datas) ne peut pas être celle de la zone 1B (qui doit tenir compte des 3 autres zones, ce qui explique pourquoi l'écart est toujours très proche du pourcentage réservé sans lui correspondre).

Maintenant pourquoi elle bouge? Personnellement ayant fait tous mes tests sur une VM, chez-moi elle n'a jamais bougé. Je viens d'ailleurs de créer ce script...
Code:

1 2 3 4 5 6 7 #!/bin/bash date while read ligne; do echo "$ligne" done < <(df -B1 -x tmpfs -x devtmpfs -x vboxsf --output=source,fstype,itotal,iused,iavail,ipcent,size,used,avail,pcent,file,target) echo
... qui va tourner en cron toutes les 10mn et enregistrer ses résultats dans un log.
Mais une hypothèse serait qu'un disque physique ayant une durée de vie et étant soumis à des pertes inévitables de secteurs, ces pertes apparaissent dans le résultat.

Citation:

Envoyé par Sve@r

Maintenant pourquoi elle bouge? Personnellement ayant fait tous mes tests sur une VM, chez-moi elle n'a jamais bougé.

Merci pour tous tes calculs (des fois je me prends la tête tout pareil pour [essayer de] comprendre...

Un jour j'ai trouvé ça chez SO [Non, pas les pompes à essence, :ptdr: :mouarf:] :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 /* * It is helpful to use a picture for calculation of disk space. * * |<--------------------- f_blocks ---------------------------->| * |<---------------- f_bfree ------------------>| * * --------------------------------------------------------------- * | USED | f_bavail | Reserved for root | * --------------------------------------------------------------- * */ https://stackoverflow.com/questions/4965355/converting-statvfs-to-percentage-free-correctly
Dans ce dessin, le mot root ne représente pas le super-user mais plutôt la racine du disque, méfiance^* !)

C'est ce que j'utilise pour mes calculs, et ce sont bien les résultats qui ont bougé, entre il y a un peu plus d'un mois et mi-août...

La seule chose que je vois entre ces deux dates, c'est une probable mise à jour de Debian, mais j'avais déjà regardé les dates de certains fichiers, sans résultat probant. Peut-être que j'ai raté quelques fichiers ?

Parce que ça,

Citation:

Envoyé par Sve@r

Mais une hypothèse serait qu'un disque physique ayant une durée de vie et étant soumis à des pertes inévitables de secteurs, ces pertes apparaissent dans le résultat.

je n'y crois pas trop pour la bonne et simple raison que j'ai deux disques strictement identiques, l'un embarque sdb1 pour le taf et l'autre sdc1, pour une première sauvegarde : ça serait quand même une sacrée coïncidence que les deux perdent le même nombre de blocs en même temps, non ?

--
^* :
Un jour j'ai recherché le mot "root" dans la page https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout
et ça m'a sorti ces lignes :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 Root directory. when a directory is created in the root directory, the inode allocator scans The root node of the extent tree is stored in The root of the tree always lives in the first data block of the directory. The rest of the root node contains metadata about If dx_root.info.indirect_levels is non-zero then the root node''s map The root of the htree is in struct dx_root, struct dx_root_info.reserved_zero struct dx_root_info.hash_version struct dx_root_info.info_length struct dx_root_info.indirect_levels struct dx_root_info.unused_flags The hash maps that exist in both struct dx_root and struct dx_node The limit and count entries in the dx_root/dx_node structures the htree index header (dx_root or dx_node)
Nulle part il n'est question du user "root", nulle part !

Et ici https://bugzilla.kernel.org/show_bug.cgi?id=93031, on voit plusieurs fois le mot "root" mais la plupart du temps en liaison avec journal, fs, flags, exemple : "If I mistype noatime to noatiem the root filesystem mounts read-only."
et aussi https://bugzilla.kernel.org/show_bug.cgi?id=114821
"the inode holds a single text file in the root directory of the drive"
"the file is in the root directory and gets listed each time the root is traversed."
(Dommage, la discussion s'arrête sur des questions de l'OP sans réponses du support depuis deux ans et demi... Pas cool.)

27/08/2022, 13h33
Sve@r

Citation:

Envoyé par Jipété

je n'y crois pas trop pour la bonne et simple raison que j'ai deux disques strictement identiques, l'un embarque sdb1 pour le taf et l'autre sdc1, pour une première sauvegarde : ça serait quand même une sacrée coïncidence que les deux perdent le même nombre de blocs en même temps, non ?

Exact je suis d'accord, mon hypothèse ne tient plus.
Une info df donne une description précise de FIELD_LIST, avec "size" qui est "Total number of blocks." Mais je ne trouve nulle part d'info qui disent que cette valeur peut changer selon le sens du doigt mouillé dans le vent.
Mon script, que tu peux (euphémisme poli pour "devrait" :mrgreen:) mettre aussi chez-toi dans ton cron, pourra peut-être donner d'autres infos (la taille n'a changé qu'une fois, on verra si elle change encore). Voici la ligne cron correspondante pour avoir ça dans un log toutes les 10 minutes: 0,10,20,30,40,50 * * * * ~moi/jipete/x.sh >>~moi/jipete/log (oui, tu as chez-moi un dossier qui t'est réservé :chin:). Après 10mn c'est probablement trop rapproché donc à toi d'affiner (perso je verrais bien ça 2 fois par jour).

Et pour "root", la traduction littérale est bien "racine". C'est cette notion de "racine" qui prévaut dans le monde Unix/Linux (exemple on parle bien de "/", racine d'un FS). La dérivation vers le user "root" n'est justement qu'une dérivation de cette notion initiale de racine. Tu auras donc plus de chances de trouver des docs qui expliquent la racine des choses que de docs qui parlent du user root.
27/08/2022, 14h41
Jipété

Citation:

Envoyé par Sve@r

(perso je verrais bien ça 2 fois par jour).

Encore plus simple et pas besoin de cron, l'exécution du script au logon et hop ! :ccool:

Je te/vous tiens au courant.

Bonjour,

Encore plus sympa et plus besoin de surveiller, c'est le script qui le fait, hé ouais ! :ccool:

D'abord, le script je l'ai bien raccourci, considérant que je n'avais besoin que des infos source et size et pas besoin de la ligne d'en-tête (qui commence en français par "Sys.", d'où le grep), ça donne scandisks.sh :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
#!/bin/bash
logfile=/data/temp/scandisks.log
 
date >> $logfile
while read ligne; do
	echo "$ligne"
done < <(df -B1 -x tmpfs -x devtmpfs -x vboxsf --output=source,size | grep -vi Sys.) >> $logfile
# saut de ligne pour séparer les blocs
echo >> $logfile
#
# ensuite, une fois les données injectées dans le fichier $logfile,
# 1- récup des valeurs
declare -a tableau
i=0
# dessous pour afficher les valeurs, pour contrôle au début mais pas utile après
# while read champ1 champ2; do tableau[$i]="$champ2"; echo $i' '${tableau[$i]}; i=$(( i+1 )); done < <(tail -n 10 scandisks.log)
while read champ1 champ2; do tableau[$i]="$champ2"; i=$(( i+1 )); done < <(tail -n 10 scandisks.log)
# puis
# 2- analyse
message="valeurs différentes !"
# ligne "cellule=" dessous à décommenter pour faire un test, avec "6" pour sda, "7" pour sdb et "8" pour sdc
# mais attention, s'il n'y a que deux disques par exemple, "6 7 8" sera à remplacer par "5 6", 
# à voir, non testé, je laisse ça à l'initiative du lecteur
# cellule="8"; tableau[$cellule]=$((tableau[$cellule]+1))
[ ${tableau[1]} != ${tableau[6]} ] && echo "sda :" $message
[ ${tableau[2]} != ${tableau[7]} ] && echo "sdb :" $message
[ ${tableau[3]} != ${tableau[8]} ] && echo "sdc :" $message

Voili voilou, s'il y a un 'blème j'ai le message "sdX : valeurs différentes !", plus qu'à trouver pourquoi, :mouarf:
:zoubi:

02/09/2022, 15h22
Sve@r

Citation:

Envoyé par Jipété

Encore plus sympa et plus besoin de surveiller, c'est le script qui le fait, hé ouais ! :ccool:

Ha oui, c'est un peu comme l'oeuf de Colomb: Simple mais fallait y penser :D

Citation:

Envoyé par Jipété

plus qu'à trouver pourquoi, :mouarf:

Point plus délicat...:question:
02/09/2022, 15h38
N_BaH

- ~~grep -vi Sys.~~ -> tail -n +2.
- while read champ1 champ2; do tableau+=( "$champ2" ); done < <(tail -n 10 "$logfile").

- puis, attention : != est un opérateur de comparaison lexicale; pour les nombres, il faut, ici, utiliser -ne.

si tu nous donnes quelques "paragraphes" de ton fichier log, on peut te faire ça proprement. :mrgreen:
d'abord, d'un point de vue algorithmique, je trouve contre productif d'ajouter la sortie de df au fichier log pour faire un tail de tout le fichier ensuite.
je ferais une seule boucle while dont la susbtitutoion de processus serait df ... | tee -a "$logfile

Citation:

Envoyé par N_BaH

si tu nous donnes quelques "paragraphes" de ton fichier log, on peut te faire ça proprement. :mrgreen:

Je peux aussi faire proprement sans...:aie:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
#!/bin/bash
 
logfile="/tmp/scandisk.log"
checkfile="/tmp/scandisk.$$"
 
# Taille fs
df -B1 -x tmpfs -x devtmpfs -x vboxsf --output=source,size | tail -n +2 >"$checkfile"	# Remerciements à N_Bah pour le "tail -n +2"...
 
# Si le log existe
if test -f "$logfile"; then
	# Lecture log
	while read ligne; do
		# Récupération date du log
		if echo "$ligne" |grep "CEST$" 1>/dev/null; then
			date="$ligne"
			continue
		fi
 
		# Traitement de chaque disque du check
		while read sd sz; do
			# Si la ligne du log ne concerne pas le sd en cours
			echo "$ligne" |grep "^$sd" 1>/dev/null || continue
 
			# Si la taille du sd a changé
			sz2="$(echo "$ligne" |awk '{print $2}')"
			test $sz -ne $sz2 && echo "Disque $sd, taille $sz différente $sz2 ($date)"
		done <"$checkfile"
	done <"$logfile"
fi
 
# Rajout du check dans le log
(
	date
	cat "$checkfile"
	echo
) >>"$logfile"
rm -f "$checkfile"

(et je n'ai pas fait de "ls") :mrgreen:

02/09/2022, 16h26
disedorgue

Et est-ce que tu as détecté des changements depuis ?

Et si non, quand tu as fait ton premier rapport de tes FS, est-ce que c'était sur une installation toute fraiche (peinture pas encore sèche) ?

Je pose cette question car dans le cas de manipulation de partition, il peut arriver que justement le décompte soit faux jusqu'au reboot de la machine et que celle-ci effectue bien un fsck full...

D'ailleurs, si tu calcules la première taille de tes disque par rapport à la deuxième, laquelle te parait la plus cohérente ?
02/09/2022, 17h31
N_BaH

Citation:

Envoyé par Sve@r

(et je n'ai pas fait de "ls") :mrgreen:

non, tu as fais ça : echo "$ligne" |awk '{print $2}, au lieu de ar=( $ligne ); echo "${ar[1]}".

Citation:

Envoyé par Ian Malcolm à John Hammond (Jurassic Park)

Vous ne commettez pas les mêmes erreurs, vous en commettez de nouvelles.

:ptdr:
02/09/2022, 17h53
Sve@r

Citation:

Envoyé par N_BaH

non, tu as fais ça : echo "$ligne" |awk '{print $2}, au lieu de ar=( $ligne ); echo "${ar[1]}".

:mrgreen:
Alors honnêtement, en le tapant je savais que ça n'irait pas mais c'est surtout parce que je n'aime pas utiliser awk pour si peu. Mais je n'aurais pas pensé aux tableaux (pas l'habitude).
Si j'avais pris un peu plus de temps je serais parti sur une solution à base de cut (avec du sed au milieu pour supprimer les espaces répétés) mais que veux-tu, j'ai été élevé dans le Bourne Shell, le truc de base qui savait faire que dalle et qui faisait tout faire par les autres...:?

Bonsoir les amis, et merci de regarder tout ça à la loupe :ccool:

Citation:

Envoyé par disedorgue

Et est-ce que tu as détecté des changements depuis ?

Pas d'autre que celui de cet été, qui justifie cette discussion (ce qui ne veut pas dire qu'il n'y en a pas eu auparavant et que je ne les aurais pas détectés...)

Citation:

Envoyé par disedorgue

Et si non, quand tu as fait ton premier rapport de tes FS, est-ce que c'était sur une installation toute fraiche (peinture pas encore sèche) ?

Non : la machine a été installée en juin 2020, les disques ont été partitionnés à ce moment et j'y ai installé Debian 10, aidé par les backports.

Quand la 11 est sortie, j'ai attendu un peu, regardé plusieurs tutos, suivi quelques discussions puis je me suis lancé, fin 2021.

Et depuis ça tourne, pas trop mal on va dire.
Sauf cette blague du changement de taille, localisé entre début juillet et mi-août, à la louche.

Citation:

Envoyé par disedorgue

Je pose cette question car dans le cas de manipulation de partition, il peut arriver que justement le décompte soit faux jusqu'au reboot de la machine et que celle-ci effectue bien un fsck full...

Rien manipulé depuis, et arrêt complet tous les soirs. Jamais vu de fsck full (vont bien, mes disques, :P)

Par ailleurs, en faisant des recherches sur la sortie des versions de la 11, je tombe sur cette phrase :

Citation:

Envoyé par debian

sa dernière mise à jour, version 11.4, a été publiée le 9 juillet 2022.

(c'est moi qui mets en gras)
source
D'ici à ce que ça soit ça, il n'y a pas loin. Mais comment savoir ? Ça me dépasse un peu...

Citation:

Envoyé par disedorgue

D'ailleurs, si tu calcules la première taille de tes disque par rapport à la deuxième, laquelle te parait la plus cohérente ?

Pas compris.

Citation:

Envoyé par N_BaH

- ~~grep -vi Sys.~~ -> tail -n +2.

OK, je prends le tail -n +2, comme ça, si un jour l'intitulé change, je ne serai pas à la rue. Merci !

Citation:

Envoyé par N_BaH

- puis, attention : != est un opérateur de comparaison lexicale; pour les nombres, il faut, ici, utiliser -ne.

Oui, mais dans ce contexte, ça ne doit pas être gênant, si la taille change, la string qui représente sa valeur va changer aussi et sera donc différente de la précédente.
Mais dans l'absolu tu as raison.

Citation:

Envoyé par N_BaH

si tu nous donnes quelques "paragraphes" de ton fichier log, on peut te faire ça proprement. :mrgreen:

J'en donne deux, car ça me fait réaliser qu'il n'est pas nécessaire de tout stocker à la queue leu leu, l'entrée précédente et l'entrée en cours devraient suffire, non ?
Code:

1 2 3 4 5 6 7 8 9 jeu. 01 sept. 2022 09:44:46 CEST /dev/sda1 205286293504 /dev/sdb1 1761439584256 /dev/sdc1 1761439584256 ven. 02 sept. 2022 13:47:09 CEST /dev/sda1 205286293504 /dev/sdb1 1761439584256 /dev/sdc1 1761439584256
Citation:

Envoyé par N_BaH

d'abord, d'un point de vue algorithmique, je trouve contre-productif d'ajouter la sortie de df au fichier log pour faire un tail de tout le fichier ensuite.
je ferais une seule boucle while dont la susbtitution de processus serait df ... | tee -a "$logfile

Ben oui, mais c'est tellement plus simple...

02/09/2022, 19h07
Sve@r

Citation:

Envoyé par Jipété

Jamais vu de fsck full (vont bien, mes disques, :P)

Ce n'était pas à lire dans le sens "disque plein" mais "fsck complet" :ptdr:
02/09/2022, 19h12
Jipété

Citation:

Envoyé par Sve@r

Ce n'était pas à lire dans le sens "disque plein" mais "fsck complet" :ptdr:

Je l'avais bien compris ainsi, :mouarf:

Citation:

Envoyé par N_BaH

je ferais une seule boucle while dont la susbtitution de processus serait df ... | tee -a "$logfile

Et je ne vois pas où et comment y insérer un "echo" pour faire un saut de ligne histoire de séparer le bloc précédent du bloc suivant (juste une histoire de lisibilité).
02/09/2022, 19h21
Sve@r

Citation:

Envoyé par Jipété

Et je ne vois pas où et comment y insérer un "echo" pour faire un saut de ligne histoire de séparer le bloc précédent du bloc suivant (juste une histoire de lisibilité).

Teste donc ma version...8-)

ou celle-ci (que je n'ai pas testée) :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
#!/bin/bash
 
log=/chemin/vers/fichier.log
 
declare -A curData logData
 
# acquisition des données du fichier log
while read c1 c2; do logData[$c1]="$c2"; done < <(tail -n 3 "$log") #parce qu'a priori il y a trois disques. l'idéal serait de variabiliser, mais est-ce indispensable ?
 
date +'%n%c %Z' >"$log"
 
# acquisition des données courantes
while read c1 c2; do curData[$c1]="$c2"; done < <(df -B1 -x tmpfs -x devtmpfs -x vboxsf --output=source,size | tail -n +2 | tee -a "$log")
 
# comparaison des tailles disque par disque
for d in "${!logData[@]}"
do
    (( ${logData[$d]} == ${curData[$d]} )) ||*echo "$d: old=${logData[$d]}, new=${curData[$d]}"
done | sort -k1,1 -t ':'

02/09/2022, 23h29
Jipété
Yep !

--N_Bah : pas mal !
Il a juste fallu que j'adapte un poil (je crois savoir que tu n'es pas sous un Debian pur et dur, donc date '%n%c %Z' >"$log" --> date: date « %n%c %Z » incorrecte, :aie: -- j'ai gardé date > "$log", on s'en fiche du format de la date maintenant, puisqu'il n'y a plus qu'une seule entrée dans le fichier -- j'ai eu la même idée en mangeant !)

Ensuite il m'a fallu corriger les typos sur la ligne

Code:

(( ${logData[$d]} == ${curData[$d]} )) ||*echo "$d: old=$logData[$d]}, new=${curData[$d]}"

c'est quoi cette étoile * avant echo et l'absence d'une accolade ouvrante { avant logData ? -->

Code:

(( ${logData[$d]} == ${curData[$d]} )) || echo "$d: old=${logData[$d]}, new=${curData[$d]}"

et aussi rajouter juste avant cette ligne un test pour vérifier le fonctionnement en cas d'autres valeurs :
Code:

1 2 # ligne à décommenter pour test du test curData[$d]=$((curData[$d]+1))
et ça donne ça, ligne décommentée :
Code:

1 2 3 /dev/sda1: old=205286293504, new=205286293505 /dev/sdb1: old=1761439584256, new=1761439584257 /dev/sdc1: old=1761439584256, new=1761439584257
C'est bien.
:ccool:

Citation:

Envoyé par N_BaH

l'idéal serait de variabiliser, mais est-ce indispensable ?

C'est prendre une enclume pour écraser un moustique : un peu disproportionné, surtout que ce code n'est pas appelé à évoluer, ou alors à peine (un disque enlevé ou un disque rajouté)

--sve@r
Pas eu le temps de me pencher attentivement sur ton code...
Cependant, une première vision rapide montre que ton dernier bloc pourrait devenir
Code:

1 2 3 4 5 6 # [Stroke]Rajout[/Stroke]Mise à jour du check dans le log ( date cat "$checkfile" echo ) >"$logfile" # un seul chevron pour écraser le contenu du fichier
Arggh ! L'éditeur ne connait pas le ~~barrage~~ [comme ça] de caractères (stroke) en mode "code", désolé :?
03/09/2022, 00h29
N_BaH

Citation:

e crois savoir que tu n'es pas sous un Debian pur et dur, donc date '%n%c %Z' >"$log" --> date: date « %n%c %Z » incorrecte,

si, si. Debian, à jour.
mais sur ArchLinux, c'est pareil : il manque le plus qui indique le début du format. :aie:

Code:

date +'%n%c %Z'

:)

pour le nombre de disques, on peut le variabiliser simplement au début du script (nbDIsk=3, et utiliser la variable,
mais ce serait une bonne idée de dynamiser l'assignation, puisque tu le dis toi-même, ça peut évoluer...
03/09/2022, 06h19
Sve@r
Citation:
Envoyé par Jipété

une première vision rapide montre que ton dernier bloc pourrait devenir

Code:

1 2 3 4 5 6 # Mise à jour du check dans le log ( date cat "$checkfile" echo ) >"$logfile" # un seul chevron pour écraser le contenu du fichier
Ah ben non, tel que je l'ai compris, le log doit archiver TOUS les historiques des tailles des partitions. Et chaque nouveau check est alors comparé à tous les précédents et affiche alors tous ceux qui avaient une taille différente.
Donc fatalement le nouveau check vient se rajouter après tous les précédents.
Mais avec un seul chevron ça le fait aussi à cette exception près que le log ne contient alors que le dernier check et que la comparaison se fait alors sur un seul. Pourquoi pas, c'est toi qui voit ton besoin 8-)
Juste que ça montre à quel point ce script est magnifique tellement il peut s'adapter facilement aux différents besoins de chacun :mrgreen:
03/09/2022, 07h06
Jipété
Bonjour,

En ce qui me concerne, je n'ai pas besoin de savoir s'il y a eu des différences dans le temps et quand, j'ai juste besoin d'être informé s'il y en a une entre maintenant et la dernière fois que le fichier a été enregistré, à charge pour moi d'initier une enquête et éventuellement de noter ça dans un autre fichier.

Enfin, sur ce point-là, chacun verra midi à sa porte.

Maintenant, si quelqu'un sait où trouver des détails parlants chez Debian, qu'il nous en informe, parce que là, même si la date de l'incident avait coïncidé tip-top avec le passage 11.3 --> 11.4 (comme je l'ai supposé), je ne sais pas quoi et où chercher pour confirmer.

Citation:

Envoyé par N_BaH

mais ce serait une bonne idée de dynamiser l'assignation, puisque tu le dis toi-même, ça peut évoluer...

Comme ça ?

Code:

nbDisks=$(df -x tmpfs -x devtmpfs -x vboxsf | tail -n +2 | wc -l)

Ça fonctionne :
Code:

1 2 $ echo $nbDisks 3
:ccool:
Plus qu'à attendre qu'un signalement sur différence se manifeste...

Ah, pas besoin de newline en début du fichier de log, donc date +'%c %Z' > "$logfile" et valà !
21/09/2022, 13h27
Sve@r

C'est mes yeux où il y avait là un nouveau post, post qui parlait d'un souci survenu hier de façon anarchique, et qui a disparu (le post, pas le souci) ???
21/09/2022, 15h12
Jipété

Citation:

Envoyé par Sve@r

C'est mes yeux où il y avait là un nouveau post, post qui parlait d'un souci survenu hier de façon anarchique, et qui a disparu (le post, pas le souci) ???

Tu n'as pas rêvé, et moi j'ai été trop précipité pour poster : mon petit script n'es pas optimisé pour travailler avec des périph (clé uzbe) insérés avant que le script soit appelé, résultat, ce dernier se prend les pieds dans le tapis, :aie:
Et bien sûr je me suis rendu compte que mon post n'était pas nécessaire, après l'avoir posté, hé ouais.

Quand j'aurai 5 minutes, je verrai ce que je peux faire...
21/09/2022, 15h28
Sve@r

Citation:

Envoyé par Jipété

mon petit script n'est pas optimisé pour travailler avec des périph (clé uzbe)

Ok, ça rassure de voir que sous Linux, l'informatique n'est pas une science aléatoire :aie:

Citation:

Envoyé par Jipété

Quand j'aurai 5 minutes, je verrai ce que je peux faire...

A mon avis, un truc style df -x ... -x ... /dev/?d* devrait faire l'affaire (au début je pensais à /dev/sd puis j'ai pensé aux disques durs ancienne génération nommés "/dev/hd" donc j'ai simplifié en "/dev/?d")

Allez, j'ai 5 minutes (et même 40, ça grave sur un vieux cd-rw en 4x, je veux tester une compil et apprendre à graver en ligne2commande puisque Brasero et k3b ne sont pas fichus de faire des cd's audio exotiques, dans le sens où au début je découpe 38 minutes en 5 morceaux enchainés, suivis par 4 morceaux indépendants, et ça patauge -- mais maintenant je comprends un peu mieux les fichiers .cue et .toc).

Donc ce matin à un moment j'ai inséré une clé et je me suis pris ça dans les dents, à l'ouverture d'une console :
Code:

1 2 3 4 # /data/temp/scandisks.sh: ligne 20: ((: 3900768256=3900768256 : tentative d''affectation à une non-variable (le symbole erroné est « =3900768256 ») # /data/temp/scandisks.sh: ligne 20: ((: 205286293504=205286293504 : tentative d''affectation à une non-variable (le symbole erroné est « =205286293504 ») # /data/temp/scandisks.sh: ligne 20: ((: 1761439584256=1761439584256 : tentative d''affectation à une non-variable (le symbole erroné est « =1761439584256 ») # /data/temp/scandisks.sh: ligne 20: ((: 1761439584256=1761439584256 : tentative d''affectation à une non-variable (le symbole erroné est « =1761439584256 »)
Là où je n'ai pas percuté, c'est qu'il y a 4 lignes (oui, une pour chaque périph. D'habitude je n'en ai que 3 quand l'outil est lancé et il semblerait que je ne l'aie jamais lancé après l'insertion d'une clé ou autre.)

Donc ce que j'ai montré c'est la fin du log d'erreur, et juste au-dessus il y avait ça :
Code:

1 2 3 4 5 6 7 8 9 / /dev/sda1 ext4 rw,noatime ├─/data /dev/sdb1 ext4 rw,noatime ├─/dbck /dev/sdc1 ext4 rw,noatime └─/media/usb /dev/sdd1 vfat rw,relatime,fmask=0022,dmask=0022,codepage=850,iocharset=iso8859-1,shortname=mixed,errors=remount-ro /dev/sda1 on / /dev/sdb1 on /data /dev/sdc1 on /dbck /dev/sdd1 on /media/usb
2 fois 4 lignes qui sont les sorties normales de mon .bashrc où on trouve findmnt | grep '/sd' et mount | awk "/\/dev\/sd/ {print \$1,\$2,\$3}", sauf pour la 4^e ligne deux fois, qui n'y est jamais, d'habitude. Du coup j'ai essayé de comprendre ce qui se passait sans bien analyser.

La ligne 20, c'est la plus longue, la 6 ici (lacicici, :ptdr:) :
Code:

1 2 3 4 5 6 7 # comparaison des tailles disque par disque for disk in "${!oldData[@]}" do # ligne dessous à décommenter pour test du test #curData[$disk]=$((curData[$disk]+1)) (( "${oldData[$disk]}" == "${curData[$disk]}" )) || echo "$disk: old=${oldData[$disk]}, new=${curData[$disk]}" done | sort -k1,1 -t ':'
La première question que je me pose, c'est pourquoi la sortie des erreurs n'est-elle pas dans l'ordre des périph's ?
La première ligne correspond à la plus petite taille, c'est la clé sdd1, suivie du ssd sda1 puis difficile de dire si c'est sdb1 ou sdc1 car ils ont les mêmes tailles.

Ensuite on peut s'interroger sur la validité des 4 messages d'erreur, que je n'ai jamais vus quand il n'y a pas de clé et qu'il n'y a que 3 périph's.

Mais ma gravure vient de se terminer, faut que je teste tout ça...

Citation:
Envoyé par Jipété
La ligne 20, c'est la plus longue, la 6 ici (lacicici, :ptdr:) :
Code:

1 2 3 4 5 6 7 # comparaison des tailles disque par disque for disk in "${!oldData[@]}" do # ligne dessous à décommenter pour test du test #curData[$disk]=$((curData[$disk]+1)) (( "${oldData[$disk]}" == "${curData[$disk]}" )) || echo "$disk: old=${oldData[$disk]}, new=${curData[$disk]}" done | sort -k1,1 -t ':'
Je ne suis jamais très à l'aise avec les "(("...

Quel est l'intérêt (la différence) de faire (( "${oldData[$disk]}" == "${curData[$disk]}" )) plutôt que [ "${oldData[$disk]}" = "${curData[$disk]}" ] ?

23/09/2022, 11h36
Sve@r
Citation:

Envoyé par jack-ft

Quel est l'intérêt (la différence) de faire (( "${oldData[$disk]}" == "${curData[$disk]}" )) plutôt que [ "${oldData[$disk]}" = "${curData[$disk]}" ] ?

C'est un test plus intelligent qui rattrape les conneries (rattrapables).
Code:

1 2 3 4 $ [ "5" = "05" ] && echo "ok" || echo "bad" bad $ (( "5" == "05" )) && echo "ok" || echo "bad" ok
On aurait pu écrire [ ${oldData[$disk]} -eq ${curData[$disk]} ] (sans guillemets parce que des chiffres et donc avec "-eq" qui sait comparer "5" avec "05") mais les doubles parenthèses ont des avantages en plus que je n'ai malheureusement plus en tête (mais j'ai confiance, N_BaH et son oeil d'aigle va vite trouver ce post et venir me les rappeler :mrgreen:)
23/09/2022, 11h48
N_BaH
par exemple :

Code:

((n=1, v=2-n, n==v))

mais attention :
Code:

1 2 (( 8 == 08 )) bash: ((: 8 == 08 : valeur trop grande pour la base (le symbole erroné est «*08*»)
alors que

Code:

test 8 -eq 08

ne se plaint pas et fait correctement la comparaison.
23/09/2022, 11h56
Sve@r
Citation:

Envoyé par N_BaH

par exemple : ((n=1, v=2-n, n==v))

Ah oui, ça c'est joli !!!
Code:

1 2 $ ((1+1 == 3-1)) && echo ok ok
:lahola: :ccool:
23/09/2022, 14h32
Jipété

Citation:

Envoyé par jack-ft

Je ne suis jamais très à l'aise avec les "(("...

Tiens, ça va te changer la vie, :plusser:
23/09/2022, 14h43
Sve@r

Citation:

Envoyé par Jipété

Tiens, ça va te changer la vie, :plusser:

Je crois que ça va changer la vie de beaucoup de monde 8O

Citation:
Envoyé par N_BaH
mais attention :
Code:

1 2 (( 8 == 08 )) bash: ((: 8 == 08 : valeur trop grande pour la base (le symbole erroné est «*08*»)
C'est aussi pour ça que si on veut être propre, on précisera la base dans laquelle on est:
Code:

1 2 3 4 $ (( 10#8 == 10#08 )) && echo ok ok $ (( 10#8 == 8#08 )) && echo ok -bash: ((: 10#8 == 8#08: value too great for base (error token is "8#08")

23/09/2022, 16h58
Sve@r
Citation:
Envoyé par disedorgue

C'est aussi pour ça que si on veut être propre, on précisera la base dans laquelle on est:

Code:

1 2 $ (( 10#8 == 10#08 )) && echo ok ok
C'est bien de vouloir être propre. Mais tu n'as pas l'impression que le premier "#8" met en commentaire tout le reste ???
Code:

1 2 $ (( 10#8 == 14#08 )) && echo ok ok
:ptdr:
23/09/2022, 17h12
disedorgue
Citation:
Envoyé par Sve@r

C'est bien de vouloir être propre. Mais tu n'as pas l'impression que le premier "#8" met en commentaire tout le reste ???

Code:

1 2 $ (( 10#8 == 14#08 )) && echo ok ok

:ptdr:
En base 14 ou en base 10, 8 est bien égale à 8...
23/09/2022, 17h14
N_BaH
pourquoi ?
Code:

1 2 3 echo $((14#08)) 8 $
23/09/2022, 18h41
Sve@r
Citation:

Envoyé par disedorgue

En base 14 ou en base 10, 8 est bien égale à 8...

Parce que le nombre avant c'est la base !!! Je pensais que la base était après "#" et que avant c'était le nombre à comparer.
Et vu que "#" c'est une marque de commentaire, je pensais que la fin de la comparaison n'était pas évaluée :ptdr:

Ok
Code:

1 2 (( 10#8 == 10#7 )) && echo ok || echo bad bad
Remarque, si la fin de la comparaison n'avait pas été évaluée, ça aurait été à cause du commentaire qui aurait alors shunté tout le reste de la ligne y compris le "echo" final :ave:
:chin: