Journal Ecriture sur disque et résistance aux arrêts brutaux.

Posté par  .
Étiquettes : aucune
0
10
juil.
2003
Cher journal, je fais appel à ton expérience.

Je dois implémenter une passerelle qui envoie un flux continue de données reçues par des capteurs (sismique, hydroacoustique, …) vers un central. Ces données devant être stockées, jusqu'à acquittement de la réception par le central.
Il était prévu d'utiliser une solution logiciel spécialisée pour le stockage sur disque, mais celle-ci ne résiste même pas un Ctrl-C (fichier de données totalement inutilisable), alors de là à résister à un arrêt brutal.

Je cherche donc une méthode de stockage sur disque qui puissent résister à un arrêt brutal. J'avais pensé à une base MySQL ou l'utilisation d'une API comme dbm. Malheureusement, je n'ai aucune idée de la résistance de ces solutions. Le but étant de perdre le moins de données possible et que le système puisse repartir sans intervention humaine (ben oui, certains pourraient être déployés dans des stations inhabitées le majeur partie du temps).
Seul impératif, il faut que cela puissent tourner sous Linux et sous Windows via Cygwin. Ben, oui le client n'est pas encore très Linux et veut un truc facilement portable sous Windows au cas il serait déçu par Linux (ce qui n'arrivera pas, je mis engage).
  • # Re: Ecriture sur disque et résistance aux arrêts brutaux.

    Posté par  . Évalué à 6.

    une bonne solution c'est une bdd qui gere les transactions come MySQL ou postgresql dans le libre (il en existe p.e. d'autres) en commitant regulierement, les derniere données non commité ne seront pas prises en compte en cas de crach (explosion de volcan? :) Dam
  • # Re: Ecriture sur disque et résistance aux arrêts brutaux.

    Posté par  . Évalué à 4.

    tu as les sytèmes de fichiers journalisés (reiser, JFS, XFS, ext3, ...) qui sont fait pour ça je crois, à condition de régler le sync avec un délai faible, et d'écrire tes données par petits bouts pour en perdre le moins possible en cas de problème
    • [^] # Re: Ecriture sur disque et résistance aux arrêts brutaux.

      Posté par  . Évalué à 4.

      Les systèmes de fichier journalisé assurent juste l'intégrité du système de fichier. Ce que je cherche, c'est une solution qui assure l'intégrité des données (contenu des fichiers ou de la base de données) ; en autre contre l'arrêt brutal de la station (ou du process) lors de la modification les données.
      • [^] # Re: Ecriture sur disque et résistance aux arrêts brutaux.

        Posté par  . Évalué à 4.

        Ce que tu cherches est très spécifique à cause de l'arrêt brutale de la machine. Un process qui meurt, le systeme d'exploitation peut reprendre avec moins de problème. C'est du software qui doit pouvoir tourner en mileu hostile. Personnellement, pour travailler sur ce genre de chose, jamais je ne ferais confiance à Linux (et encore moins Windows !). Non, pas qu'ils sont mauvais mais parce qu'ils n'ont jamais été prévus pour les milieux hostiles. Comme je suppose que tu n'as pas le choix sur la plateforme de développement, je te conseille d'ajouter un onduleur/batterie au systeme. Si la courant vient à lacher, il y aura assez d'énergie pour assurer un arrêt en douceur. Prévoir aussi un arrêt en douceur du process en interceptant les demandes d'arrêt (signaux ou autres) de la part du systeme d'exploitation.
        • [^] # Re: Ecriture sur disque et résistance aux arrêts brutaux.

          Posté par  . Évalué à 1.

          Linux supporte très bien les coupures de courant ou les reset. Il n'y a aucun problème sur ce point. Par contre le problème c'est le hardware. Lors d'une coupure de courant certains hardware peuvent passer par des états "bizarre" et mettre le bordel.

          Si tu as du bon hard (prend des disques SCSI qui supportent les coupures de courant) il n'y a pas de problème avec Linux.

          Et si linux est l'un des systèmes les plus utilisés en embarqué, c'est pas pour rien.
          • [^] # Re: Ecriture sur disque et résistance aux arrêts brutaux.

            Posté par  . Évalué à 1.

            Je parlais d'environnement hostile (un serveur est rarement considéré comme dans un environnement hostile -- de plus le PC n'est pas fait pour ça). Linux peut-être utilisé dans l'embarqué, je ne dit pas le contraire. Mais lorsque tu te retrouves à faire face à des environnements hostiles (en général le petit embarqué) et que tu dois faire du stockage de quelques données, linux et ces systèmes de fichier ne sont pas adaptés à moins d'avoir une batterie pour faire atterrir le systeme en douceur. Dans ce cas, on se reporte sur des environnements propriétaires où les structures de données (OS et application) sont adaptés pour ne pas se corrompre (c'est d'ailleurs assez proche du journaling parfois mais pas tout à fait parce que l'on rajoute aussi du CRC un peu partout). ce genre de système n'est pas un foudre de guerre en terme de vitesse mais c'est très robuste.

            Au passage, si Linux est le plus utilisé en embarqué, c'est parce qu'il offre une pile TCP/IP et du stockage. L'embarqué (le high-end) a maintenant pas mal de capacité de ce coté grâce aux progrès technologique et la disponibilité du code source permet de construire des solutions flexible. Par exemple, une borne d'accès Wifi est idéale pour acceullir Linux (réseau et pas de stockage donc tout en RAM pour les data).
            Si tu n'as pas besoin de la pile réseau et de faire du stockage Linux n'est plus très interressant. On se retrouve à ce niveau vers le petit embarqué, d'ailleurs QNX se débrouille mieux en terme de consommation mémoire dans ce contexte.
      • [^] # Re: Ecriture sur disque et résistance aux arrêts brutaux.

        Posté par  . Évalué à 5.

        Tu ne peux pas mettre un onduleur pour empécher ces arrêts brutaux ? Pour les arrêts du process c'est pas très dur d'intercepter les signaux style CTRL+C (cf. man 2 signal). Enfin pour tes données le moyens le plus sur de ne pas en perdre c'est la méthode des log : ce qui est enregistré n'est pas modifié ni réécrit, on ajoute juste des données mais tout dépend de comment tu veux les gérer ...
      • [^] # Re: Ecriture sur disque et résistance aux arrêts brutaux.

        Posté par  . Évalué à 5.

        N'importe quel système avec le commit/rollback fait l'affaire. MySQL dans sa dernière version le permet, de même que la plupart des bases de données. Si y'a pas besoin de la puissance d'une base de donnée (tu ne fais que stocker des données brutes volatiles), rien ne t'interdit de sauvegarder toi même dans un format malin. Ca n'a rien de compliqué pour peu que tu utilises un format binaire. C'est ce que je fais pour stocker mes résultats de simulation numérique et j'ai jamais eu de problème malgré toutes les pannes qu'il y a pu y avoir. Après tout, ceux qui écrivent des bases de données ne font appel à aucune méthode miraculeuse, c'est juste des fopen, fwrite, fread, fseek, ftell et fclose. Le tout est bien sûr que le système de fichier soit journalisé.
      • [^] # Re: Ecriture sur disque et résistance aux arrêts brutaux.

        Posté par  . Évalué à 0.

        ext3fs permet de journaliser les data AUSSI mais comme c'est plus lent c'est pas activé par défaut.
        par defaut ext2fs est monté en data=ordered (pas journalisé)
        mais tu peut specifier data=journal ...

        man mount


        (ceci dit, une base de donnée c'est peut-etre pas mal ...)
        • [^] # Re: Ecriture sur disque et résistance aux arrêts brutaux.

          Posté par  . Évalué à 1.

          Je crois que tu fais des mélanges.
          data=ordered : les données sont journalisé (écriture des données, puis mise à jour du système de fichier).

          C'est la valeur par défaut sous RedHat (et surement d'autre). C'est aussi pour ça que les gens trouvent reiserfs rapide (lui il journalise pas les données).
    • [^] # Re: Ecriture sur disque et résistance aux arrêts brutaux.

      Posté par  . Évalué à 1.

      mieux régler le sync est en effet la premiere chose a faire.

      sinon qu'est ce qui te fait penser que ton système peut s'arreter brutalement?
  • # Re: Ecriture sur disque et résistance aux arrêts brutaux.

    Posté par  . Évalué à 1.

    Pose cette question sur la mailing-liste postgres ; je suis certain que c'est un défi qui les intéressera :-)
  • # Re: Ecriture sur disque et résistance aux arrêts brutaux.

    Posté par  . Évalué à 2.

    Merci pour ces réponses.

    Je vais opter pour une base de donné MySQL, pour deux raisons :
    - En effet, il est possible de tester l'intégrité des tables et de les réparer très simplement ("CHECK TABLE", "REPAIR TABLE").
    - La recherche et l'accès aux données vont être facile à coder.

    Petite précision :
    En faite, il y relativement peut de chance que la machine s'arrête brutalement, mais au cas où ça arriverait, perdre quelques données n'est pas gênant, mais il faut impératif que le système reparte de lui-même. La bibliothèque proposée par le client génère un "Segmentation Fault" à la réouverture des fichiers de données si le process est interrompu durant une écriture et ne propose aucune fonction pour vérifier l'intégrité des fichiers avant d'y accéder.
    • [^] # Re: Ecriture sur disque et résistance aux arrêts brutaux.

      Posté par  . Évalué à 1.

      heu .. si t'as le source ca vaudrait peut-etre le coup de debugguer la lib parce que faire un segmentation fault a cause de datas ... c'est pas clean !
    • [^] # Re: Ecriture sur disque et résistance aux arrêts brutaux.

      Posté par  . Évalué à 2.

      Prends PostgreSQL. Il a un "vrai" support de transaction (sur plusieurs table à la fois) et n'est pas plus dure à utiliser que mysql si tu l'utilise comme Mysql (après il a d'autre fonctionnalités nettement plus compliquées). De même postgresql offre les backup à chaud. C'est-à-dire que même si ton backup prend 2 heures (ce qui serait étonnant) il n'aura pas de transaction intermédiaire. C'est le backup à un instant t.
  • # Re: Ecriture sur disque et résistance aux arrêts brutaux.

    Posté par  . Évalué à 3.

    linux en ext3 + postgresql + onduleur et un shutdown propre quand
    l'onduleur ne peut plus fournir.

    ou alors
    - le groupe electrogène qui se met en route automatiquement
    ou
    - un bon vélo couplé à une dynamo et du guronsan
    ou
    - une éolienne à sécater les oiseaux migrateurs
    ou
    - des panneaux solaires

Suivre le flux des commentaires

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