This is a multi-part message in MIME format.
On 07/11/2022 06:56, AleX wrote:
Le dim. 6 nov. 2022 à 22:09, Basile Starynkevitch <basile@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) <https://man7.org/linux/man-pages/man2/sync.2.html> 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) <
https://man7.org/linux/man-pages/man2/sync.2.html>
<
https://man7.org/linux/man-pages/man2/sync.2.html#top_of_page>
*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 <
https://www.gnu.org/software/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) <
https://man7.org/linux/man-pages/man2/sync.2.html> 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
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) <
https://man7.org/linux/man-pages/man1/sync.1.html> (qui appelle sync(2) <
https://man7.org/linux/man-pages/man2/sync.2.html>...) 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.
--
Basile Starynkevitch<
basile@starynkevitch.net>
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 07/11/2022 06:56, AleX wrote:<br>
</div>
<blockquote type="cite" cite="mid:
CAJRrEe7eLXqP0iuaR+mKsgf_p13HCDgNiDr9t9hmQxq6mjt_vA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr"><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Le dim. 6 nov. 2022 à 22:09,
Basile Starynkevitch <<a
href="mailto:
basile@starynkevitch.net"
moz-do-not-send="true" class="moz-txt-link-freetext">
basile@starynkevitch.net</a>>
a écrit :<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>
<p>Bonsoir la liste APRIL et Debian User French</p>
<p><br>
</p>
<p>J'ai développé en un soir l'utilitaire <i>sync-periodically</i>
<a href="
https://github.com/bstarynk/misc-basile/blob/master/sync-periodically.c"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">
https://github.com/bstarynk/misc-basile/blob/master/sync-periodically.c</a></p>
<p>(GPLv3+)</p>
<p>Comme son nom l'indique, il appelle toutes les quelques
secondes <a
href="
https://man7.org/linux/man-pages/man2/sync.2.html"
target="_blank" moz-do-not-send="true">sync(2)</a> 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.<br>
</p>
<p>1. Comment le démarrer proprement au démarrage d'un
Debian (ou Ubuntu) récent?</p>
<p>2. <b>Comment le packager dans Debian?</b></p>
</div>
</blockquote>
<div>
<div>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)</div>
<div><br>
</div>
<div>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 ?)
<div><br>
</div>
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.</div>
</div>
</div>
</div>
</blockquote>
<p><br>
</p>
<p>D'après la page du manuel de l'appel système <font
face="monospace"><a moz-do-not-send="true"
href="
https://man7.org/linux/man-pages/man2/sync.2.html">sync(2)</a></font><br>
</p>
<h2><a
href="
https://man7.org/linux/man-pages/man2/sync.2.html#top_of_page"><span
class="top-link"></span></a></h2>
<pre> <b>sync</b>() causes all pending modifications to filesystem metadata
and cached file data to be written to the underlying filesystems.
</pre>
<p>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 <a moz-do-not-send="true"
href="
https://www.gnu.org/software/emacs/">GNU emacs</a> 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 <font face="monospace"><a
href="
https://man7.org/linux/man-pages/man2/sync.2.html"
target="_blank">sync(2)</a></font> toutes les deux secondes
évite de perdre trop de fichiers. En effet, leurs données et
métadonnées sont pratiquement maintenues en RAM<br>
</p>
<p>Pour un dévelopeur, ça peut éviter une heure de perdue. Bien sûr,
si on 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.<br>
</p>
<p>D'ailleurs, à l'époque de SunOS3.5 (dans les années 1985, station
Sun3/160), sur des disques rotatifs, la documentation précisait <i>explicitement</i>
qu'il fallait lancer la commande <font face="monospace"><a
moz-do-not-send="true"
href="
https://man7.org/linux/man-pages/man1/sync.1.html">sync(1)</a></font>
(qui appelle <font face="monospace"><a moz-do-not-send="true"
href="
https://man7.org/linux/man-pages/man2/sync.2.html">sync(2)</a></font>...)
avant tout risque de coupure de courant, ou tout arrêt de la
machine par la commande <font face="monospace">shutdown</font>.<br>
</p>
<p>A l'époque, un <font face="monospace">fsck</font> de réparation
pouvait durer des dizaines de minutes, et le <font
face="monospace">sync </font>faisant gagner des heures de
travail. Perdre un fichier source est énervant pour un dévelopeur.<br>
</p>
<blockquote type="cite" cite="mid:
CAJRrEe7eLXqP0iuaR+mKsgf_p13HCDgNiDr9t9hmQxq6mjt_vA@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div> <br>
</div>
</div>
</div>
</blockquote>
<pre class="moz-signature" cols="72">--
Basile Starynkevitch <a class="moz-txt-link-rfc2396E" href="mailto:
basile@starynkevitch.net"><
basile@starynkevitch.net></a>
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/
</pre>
</body>
</html>
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)