Forum Astuces.divers [Admin] Fiabilité des écritures disque

Posté par  .
Étiquettes : aucune
0
26
fév.
2005
Vous ne le saviez peut être pas, mais sous les systèmes Unix, les caches en écriture de disques doivent être désactivés, notamment si vous utilisez un système de fichiers tel que reiserfs.

Dans le cas contraire, en cas de bloquage violent (panne hardware ou de panne d'alimentation), vous perdrez les données stockées dans ce cache, et corromprez votre système de fichiers (d'une manière irrécupérable pour ces blocs).

Pour les disques IDE, hdparm option "-W 0", et pour les disques SCSI voir scsitools.

Il faut aussi savoir que la longévité du disque en sera amoindrie, les constructeurs jouant sur la taille du cache pour limiter les accès en écriture.

  • # plop

    Posté par  (site web personnel) . Évalué à 1.

    une url qui va dans ton sens:
    http://sr5tech.com/write_back_cache_experiments.htm(...)

    • [^] # Re: plop

      Posté par  (site web personnel) . Évalué à 1.

      Savoir faire des sync ou Alt+Impr+s permet de faire la même chose après un gros travail de code...

      L'avantage est que cela ne pourri pas le disque en dehors du travail...

      • [^] # Re: plop

        Posté par  . Évalué à 1.

        Dans les tests on parle des controllers raid, en oubliant de spécifier
        que ces controllers sont équipés d'une batterie pour éviter la perte de
        data lors d'une coupure courant brusque.

        • [^] # Re: plop

          Posté par  . Évalué à 1.

          Sauf que la batterie protège la RAM du contrôleur RAID, et pas la RAM du PC. On peut donc toujours avoir intérêt à désactiver le cache en écriture au niveau OS.

          • [^] # Re: plop

            Posté par  . Évalué à 1.

            ce qui n'a strictement rien à voir avec cette astuce, puisqu'on parle ici de le désactiver au niveau des disques.

            D'autre part, reiserfs a été évoqué : c'est en effet un système de fichier journalisé, qui pose le plus problème en l'occurence, en raison de l'utilisation intensive du journal pour éviter les pertes de données en cas de crash (contrebalancer le problème induit par le cache disque en écriture de l'OS, donc).

            Ce qu'on risque de perdre en raison des caches des disques en écriture, c'est les inscriptions dans le journal, ce qui peut amener à corrompre le système de fichier, puisque pour éviter la corruption fsck rejoue le journal en le considérant (à tort dans ce cas) complet et marque ensuite les systèmes de fichiers comme "clean". C'est tout le problème.

            Heureusement, on utilise courament sur les serveurs des controlleurs raid possédant beaucoup de mémoire (128Mo est courant aujourd'hui) et une batterie pour justement pallier ce problème, ce que signalait momsh. Bref sans vouloir t'offenser, t'es un poil à côté du sujet :)

            Cela dit ton commentaire est intéressant, justement parce que c'est une confusion courante : cache du disque, cache du contrôleur RAID, cache de l'OS, en lecture, en écriture... Pas toujours simple de s'y retrouver; surtout que chaque constructeur utilise sa propre terminologie.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.