Discussion :

[Jipété]

Bonjour,

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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,

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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,
(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,

[Sve@r]

Bonjour

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

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 bash :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[Jipété]

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, ] :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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,

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[Sve@r]

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" ) 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é ). 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.

[Jipété]

(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 !

Je te/vous tiens au courant.

[Jipété]

Bonjour,

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

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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,

[Sve@r]

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

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

plus qu'à trouver pourquoi,

Point plus délicat...

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

[Sve@r]

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

Je peux aussi faire proprement sans...

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

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")

[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 ?

[N_BaH]

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

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

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

[Sve@r]

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

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

[Jipété]

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

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

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.

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, )

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

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

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.

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

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

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

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

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

[Sve@r]

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

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

[Jipété]

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

Je l'avais bien compris ainsi,

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

[Sve@r]

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

[N_BaH]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 ':'

[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, -- 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 :

Sélectionner tout - Visualiser dans une fenêtre à part

    (( ${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 :

Sélectionner tout - Visualiser dans une fenêtre à part

    (( ${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 :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
# ligne à décommenter pour test du test
    curData[$d]=$((curData[$d]+1))

et ça donne ça, ligne décommentée :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
/dev/sda1: old=205286293504, new=205286293505
/dev/sdb1: old=1761439584256, new=1761439584257
/dev/sdc1: old=1761439584256, new=1761439584257

C'est bien.

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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é

[N_BaH]

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.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[Sve@r]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
Juste que ça montre à quel point ce script est magnifique tellement il peut s'adapter facilement aux différents besoins de chacun