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.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
