Dimanche 1 octobre 2006, 20:17:32 CEST, Pascal Hambourg a écrit : >[...] > > Bien que je sois entièrement d'accord avec la perte de performance > > qui pourrait en résulter, je pense qu'un SGBD doit jouer avec fsync > > et consort. C'est _vraiment_ leur boulot de s'assurer de > > l'intégrité des données. > > Je ne dis pas le contraire. Mais je dis que ni l'OS ni le SGBD ne > peuvent rien faire en cas de coupure intempestive de l'alimentation. > Si l'interruption se produit au milieu d'une écriture "atomique" pour > le SGBD (mais pas pour l'OS ou le disque), les données encore en RAM > système en attente d'écriture ne sont pas écrites. Alors que les > données dans le cache d'écriture du disque ont une chance d'être > enregistrées. > > Les seuls cas que je vois où il y a vraiment un intérêt pour l'OS ou > l'application de s'assurer de l'écriture effective, c'est pour la > gestion de l'alimentation (extinction ou mise en veille [1]) et > l'extraction d'un support amovible. > > [1] J'ai eu connaissance d'un bug affectant Windows avec certains > disques récents ayant un gros cache : à la commande d'extinction, > Windows n'attendait pas assez longtemps que les données en cache > soient effectivement enregistrées sur le disque avant de couper > l'alimentation.
De toute façon, si on a des données importantes, on sécurise son alimentation de telle façon que les coupures n'aient pas de conséquence graves (« onduleur » p.ex.). -- Sylvain Sauvage
