[April technique] comment démarrer un démon syncperiodically (et financer RefPerSys)

[Basile Starynkevitch <basile AT starynkevitch.net>]

On 07/11/2022 06:56, AleX wrote:

Le dim. 6 nov. 2022 à 22:09, Basile Starynkevitch <basile AT starynkevitch.net> a écrit :

Bonsoir la liste APRIL et Debian User French

J'ai développé en un soir l'utilitaire sync-periodically https://github.com/bstarynk/misc-basile/blob/master/sync-periodically.c

(GPLv3+)

Comme son nom l'indique, il appelle toutes les quelques secondes sync(2) sur un ordinateur Linux (desktop ou laptop avec beaucoup de RAM, par exemple plus de 32Go de RAM) pour vidanger les caches des fichiers sur le disque.

1. Comment le démarrer proprement au démarrage d'un Debian (ou Ubuntu) récent?

2. Comment le packager dans Debian?

Ca me fait penser aux utilitaires qui existait il y a bien longtemps (windows 98, je ne connaissais pas encore le libre) pour 'libérer de la RAM', ce qui n'a aucun sens puisque justement, plus on exploite la RAM et plus le système est réactif : ça ne sert à rien d'avoir 50% de la ram non employée (il faut par contre qu'elle se libère bien automatiquement lorsque l'on a un autre besoin, mais c'est le rôle de l'OS de gérer ça)

Au final, quel peut bien être l'intérêt de forcer une E/S régulièrement sur disque physique ? (et d'ailleurs, je ne trouve pas de 'seuil'.. le mécanisme s'applique dès le premier octet ?)

je précise que je n'ai aucune compétence pointue en code, mais je m'interroge sur l'utilité de ce genre de fonction.

D'après la page du manuel de l'appel système sync(2)

       sync() causes all pending modifications to filesystem metadata
       and cached file data to be written to the underlying filesystems.

Si on a la chance d'avoir une machine puissante de bureau -sans batterie ni onduleur-, avec plein de RAM (par exemple 32Go), et qu'on modifie souvent des fichiers (par exemple parce qu'on code quelquechose sous GNU emacs en C++) et qu'on a la malchance de subir une coupure de courant inopinée (orage, quelqu'un qui se prend les pieds dans le cable, etc...), appeler sync(2) toutes les deux secondes évite de perdre trop de fichiers. En effet, leurs données et métadonnées sont pratiquement maintenues en RAM

Pour un dévelopeur, ça peut éviter une heure de perdue. Bien sûr, si on a un disque rotatif, ça l'use un peu plus (la mécanique est sollicitée toutes les deux secondes). Mais de nos jours ces disques sont fiables mécaniquement.

D'ailleurs, à l'époque de SunOS3.5 (dans les années 1985, station Sun3/160), sur des disques rotatifs, la documentation précisait explicitement qu'il fallait lancer la commande sync(1) (qui appelle sync(2)...) avant tout risque de coupure de courant, ou tout arrêt de la machine par la commande shutdown.

A l'époque, un fsck de réparation pouvait durer des dizaines de minutes, et le sync faisant gagner des heures de travail. Perdre un fichier source est énervant pour un dévelopeur.

(et je cherche toujours un consortium en rapport avec RefPerSys)

-- 
Basile Starynkevitch                  <basile AT starynkevitch.net>
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/