Vanuxem Grégory a écrit :
En gros, ton disque dur seble avoir l'écriture différé active. Du coup, même quand l'OS pense que c'est écrit, il se peut que les données ne soient que sur le cache ram du disque dur. Du coup, en cas de coupure de courant, ben les données s'envolent.Bof. Le même problème existe de toute façon au niveau supérieur avec les données en attente d'écriture dans le cache de l'OS.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.