Fonctionnement aléatoire de commandes système dans un script

Version imprimable

Bonjour,

je suis en train d'automatiser la création de disques virtuels orientés VBox (fichiers .vdi, donc), et je vais de surprise en surprise, concernant le fonctionnement aléatoire de mon script.

Certaines parties n'ont pas été touchées depuis plusieurs semaines, ce n'est pas sur elles que je travaille, et pourtant ce sont elles qui échouent, aléatoirement ; je me demande si ce n'est pas lié au multi-tâches et à d'autres choses similaires qui se passent dans notre dos et qu'on ne voit pas...

Deux exemples :
extrait 1
Code:

1 2 3 4 5 6 7 8 sync # -2- connexion du fichier-disque echo " connexion du fichier $fichier sur le point de montage $vdisque..." vdfuse -t VDI -f $fichier $vdisque > /dev/null 2>&1 # erreur 1 intermittente ici, malgré le sync au dessus, et pourtant # mount montre que le fichier est monté ! Alors pourquoi erreur 1 ? err=$?
La solution (mais est-ce que le fait que ça fonctionne 10 ou 20 fois c'est valable ? Est-ce que ça ne va pas planter à la 21^e fois ?) pour le moment consiste à rajouter sleep 0.5 juste avant l'appel à vdfuse mais franchement, ça fait chichi...
Ça fait chichi parce que j'ai mis 0.5 complètement au pif, ça aurait pu être 0.8 ou 0.3, ou pourquoi pas 0.1 ou tout autant 10... J'aime pas les machins pifométriques :furax:

Et question subsidiaire, à quoi sert sync s'il faut le compléter / le blinder par un sleep ?
Quelqu'un connaît une autre commande, moins aléatoire et plus définitive ?

extrait 2
Code:

1 2 3 4 5 6 sync # -3b- formatage partition echo " formatage de la partition $vdisque/$partoch..." mke2fs -q -t ext4 -F -F $vdisque/$partoch err=$?
Même topo, un message d'erreur abscons généré par mke2fs que je n'avais jamais vu lors des précédents tests, solutionné (really ?) en rajoutant un sleep 0.5 après le sync qui termine / clôture l'étape précédente...

Bonne journée,

13/04/2015, 12h41
disedorgue

Bonjour,

Pas trop de solution, sauf peut-être en faisant un second sync après un sleep.

la commande sync flush tous les buffers ouvert sur disque mais n'attend pas necessairement que cela soit fini pour rendre la main:

Citation:

DESCRIPTION
The sync() function writes all information in memory that
should be on disk, including modified super blocks, modified
inodes, and delayed block I/O.

Unlike fsync(3C), which completes the writing before it
returns, sync() schedules but does not necessarily complete
the writing before returning.
13/04/2015, 12h45
Escapetiger

Citation:

Envoyé par Jipété

Et question subsidiaire, à quoi sert sync s'il faut le compléter / le blinder par un sleep ?
Quelqu'un connaît une autre commande, moins aléatoire et plus définitive ?

Salut Jipété,

La question n'est pas du tout subsidiaire, sync sert à synchroniser l'écriture, la validation (on dirait le commit pour une base de données) pour le fs/partition qui peut avoir un temps de latence plus ou moins long :

Une astuce d'administration au long cours "unixienne" pour le valider de façon quasi-sûre :
sync ; sync qui "rends la main" une fois l'opération effectuée.

[edit] On peut même essayer de blinder la commande par sync ; sync ; wait
13/04/2015, 19h25
Jipété

Merci pour vos retours, :ccool:

Citation:

Envoyé par disedorgue

la commande sync flush tous les buffers ouvert sur disque mais n'attend pas nécessairement que cela soit fini pour rendre la main:

Citation:

DESCRIPTION
The sync() function writes all information in memory that
should be on disk, including modified super blocks, modified
inodes, and delayed block I/O.

Unlike fsync(3C), which completes the writing before it
returns, sync() schedules but does not necessarily complete
the writing before returning.

Où as-tu trouvé ces détails croustillants ?
Mon man ne les affiche pas. Tu es allé fouiller dans le code source ? S'il faut faire ça avec toutes les commandes externes, la rédaction de scripts ne va pas être très productive, :mrgreen:

Citation:

Envoyé par Escapetiger

On peut même essayer de blinder la commande par sync ; sync ; wait

Je vais sans doute tenter cette voie, merci pour le tuyau, merci pour les infos !
13/04/2015, 19h34
disedorgue

Je reconnais que ce n'est pas le man de linux mais d'un solaris :aie:

Bonjour,

je déterre cette discussion car cette histoire de délai pifométrique ne me convenant pas trop, intellectuellement parlant, comme j'avais 5 minutes j'ai fouillé et je suis tombé sur... une légende urbaine, désolé Escapetiger :

Citation:

Envoyé par Escapetiger

On peut même essayer de blinder la commande par sync ; sync ; wait

Mais il y a un fond de vérité, un peu de lecture ici et là et encore là.

Le plus ennuyeux àmha c'est que si j'ai bien compris, l'appel de sync demande au kernel de dire au pilote du disque de vider ses buffers, mais ensuite le disque prend le temps dont il a besoin pour faire le taf hardware, ce qui est toujours plus long que le retour de la fonction, d'où ce délai que j'avais constaté empiriquement et que d'autres ont noté également, ce qui est ennuyeux car on n'a aucun moyen de savoir quand le disque a vraiment fini d'écrire...
Extrait du /usr/src/linux_version/fs/sync.c :
Code:

1 2 3 4 5 /* * Finally, we writeout all block devices because some filesystems (e.g. ext2) * just write metadata (such as inodes or bitmaps) to block device page cache * and do not sync it on their own in ->sync_fs(). */
Il faudrait peut-être aller explorer les internals profond profond des pilotes de disque, ce qui me dépasse grave.
Dans l'attente et en manière de contournement, sync; sleep(1) comme je l'avais supposé devrait être suffisant et moins marabouté que sync; sync; wait je pense, d'autant plus que l'appel kernel le fait déjà deux fois de lui-même (voir la proc do_sync_work).

That's all, folks !

03/08/2016, 21h09
Escapetiger

Citation:

Envoyé par Jipété

(...)
je déterre cette discussion car cette histoire de délai pifométrique ne me convenant pas trop, intellectuellement parlant, comme j'avais 5 minutes j'ai fouillé et je suis tombé sur... une légende urbaine, désolé Escapetiger :
(...)
Mais il y a un fond de vérité, un peu de lecture ...

Pas de souci Jipété & disedorgue, merci pour ces liens oh combien instructifs, ces habitudes étaient un moyen empirique, en production, également de se prémunir par rapport aux technologies de l 'époque...

Citation:

Envoyé par Jipété

Le plus ennuyeux àmha c'est que si j'ai bien compris, l'appel de sync demande au kernel de dire au pilote du disque de vider ses buffers, mais ensuite le disque prend le temps dont il a besoin pour faire le taf hardware, ce qui est toujours plus long que le retour de la fonction, d'où ce délai que j'avais constaté empiriquement et que d'autres ont noté également, ce qui est ennuyeux car on n'a aucun moyen de savoir quand le disque a vraiment fini d'écrire...

Tout à fait et c'est là, que "ta" problématique rejoint les contraintes de type temps-réel, abordées en leur temps par exemple (ce n'est pas du Linux mais du "Sun/Solaris") comme avec l'OS Chorus :

https://fr.wikipedia.org/wiki/ChorusOS

ps :
Je rectifie, le wait n'est pas approprié, il s'agissait d'un troisième sync

ps 2:
Sun Microsystems rachète le français Chorus Systèmes
Les Echos | Le 11/09/1997