Journal Remplacer un disque dur par une compact flash, autre expérience

Posté par  .
Étiquettes :
0
12
juin
2007
Suite au journal de dark_star du 16 mai 2007 [1] je me suis décidé à faire mes achats :
- CompactFlash - 8 Go - High Speed 266x Transcend (108¤ + 7,54¤ de port) sur www.lcdi.fr [2] (baissé à 98¤)
- Convertisseur Compact Flash Vers IDE 3.5" (40 pins) - Bootable MALE (7,90¤ + 3¤ de port) sur www.kalea-informatique.com [3]
Contrairement à lui, j'ai opté pour une carte avec une vitesse "très" élevée.


Les caractéristiques de la carte (d'après le site du constructeur [4]):
- 266X (40Mo/s en lecture/écriture)
- 1 million d'écritures
- statut défini à 'fixed' et non à 'removable'
- gère le PIO mode 6 et Ultra DMA mode 4

Les caractéristiques de l'adaptateur IDE <=> CF :
- la CF est Bootable
- gère le CF de type I et II
- connecteur Floppy/Disquette pour l'alimentation
- se branche sur une nappe IDE pour disque 3.5" (pas directement sur la carte mère)
- COMPATIBLE AVEC LES CARTES DMA
- Jumper Maitre/Escalve
Une fois déballé :
- gère la norme CF v2.0 et IDE/ATA 33
- mode true-IDE
- DMA 33


Passons maintenant à l'installation d'un OS :)
(Les premiers tests ont été fait avec la CF seule sur la nappe primaire, et 2 lecteur/graveur en secondaire.)


Test n°1 : Installation de Debian Etch
- début de l'installation, détection du matériel
=> Disque dur non trouvé, installation abandonnée.
(le disque est bien reconnu comme /dev/hda quand on va dans la console pendant l'installation)


Test n°2 : Installation de Debian Sarge
- la CF est reconnue, l'installation se poursuit
- installation de Grub => plantage à 50% à chaque fois
- installation de Lilo => ça passe

* 1er démarrage :
Il y a eu quelques erreurs de DMA lors du boot, ce qui est étrange car les 2 composants sont censés gérer ça comme il faut. Le boot est plus que silencieux, et à l'air aussi rapide qu'un disque dur.
Je teste ensuite la copie d'un fichier en local (de la carte sur elle-même) : une fraction de seconde, vraiment impressionnant.

Ce qui m'intéresse, ce sont les débits CF => HDD et vice-versa. Je branche donc mon disque dur en slave, et reboot le PC.
=> Freeze complet du PC lors du boot avec des erreurs DMA.


Test n°3 : Installation de Debian Sarge
Option de boot : ide0=nodma (de mémoire)
Ayant vu sur des forums qu'il fallait désactiver le DMA pour certaines cartes, je tente le coup avec une réinstallation (bien que le DMA m'intéresse pour les débits de 40Mo/s, et que cela désactive aussi le DMA pour le disque dur branché sur la même nappe ce qui n'est vraiment pas envisageable sauf pour les tests).
Cette fois-ci Grub s'est installé, mais le freeze est de retour lorsque je branche le 2ème disque dur.


Test n°4 : Installation de Ubuntu 7.04
L'installation se passe bien, à priori, sauf que je n'ai pas vu la page de fin d'installation (je n'ai pas réagi tout de suite, je n'en installe pas tous les jours :p).
Lors du reboot, je me retrouve avec un lilo (installé précédemment avec la Debian Sarge), donc l'installation a sûrement planté lors de la phase avec Grub, pas mal...


Test n°5 : Branchement sur un autre PC
Pour essayer de déterminer un peu plus précisément l'origine de la panne, je branche la CF sur un autre PC, seule, sur la nappe primaire.
=> exactement le même freeze que sur l'autre PC, sauf qu'il n'y a même pas de 2ème disque dur de branché.


Pour conclure, je ne saurais pas dire avec précision si le problème vient de la CF ou de l'adaptateur bien que je penche + fortement pour le 2ème cas. Je vous recommande donc d'être prudent lors de l'achat, voir d'acheter un produit déjà testé dans des conditions similaires à votre utilisation.

Quelques questions sans réponse :
- le mode Ultra-DMA de la CF et la gestion du DMA 33 par le convertisseur : est-ce bien la même chose ? existe-t-il un mode DMA (sans ultra) dans lequel configurer la CF avec hdparm (de mémoire hdparm affiche les 2 modes indiqués par le contructeur) ?
- le DMA 33 nécessite-t-il une fréquence de fonctionnement spécifique de la carte mère (ou que sais-je comme sous composant) ?


Je peux faire d'autres tests si besoin, et donner + détails sur les configs de test. Si vous avez qq pistes pour m'aider à faire fonctionner tout ça, je les écouterais avec plaisir :) (non, pas de test d'XP sur ma bécane svp :p)


[1] http://linuxfr.org/~dark_star/24475.html
[2] http://www.lcdi.fr/index.php?activate=affichage_produit&(...)
[3] http://www.kalea-informatique.com/mag/fr/product-158494.htm
[4] http://www.transcend.nl/Products/ModDetail.asp?ModNo=148&(...) (onglet Spécificités et Dispositifs)
  • # hdparm

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

    Test avec hdparm pour utiliser un mode dma de rang inférieur.

    "La première sécurité est la liberté"

    • [^] # Re: hdparm

      Posté par  . Évalué à 2.

      Après quelques autres tests avec :
      - la CF branchée et le disque dur
      - les options de boot : ide=nodma nodma
      Le boot a réussi à se terminer.
      Cependant, les débits HDD => CF vont de 2,6Mo/s à 2,7Mo/s...

      Toujours sans dma au boot, je tente de l'activer avec hdparm (sur les 2) (oui, n'ayons peur de rien :D) :
      - copie HDD => 18Mo/s à 20Mo/s
      C'est déjà mieux, sauf que le système est plus qu'instable... ("attempt to acces beyond end of device", "dma timeout error")

      Je tente la même chose puis configure en udma0 (les 2 toujours) :
      - débit de 8Mo/s à 9Mo/s.
      Système tout aussi instable.


      Pour ta proposition, est-il possible de le faire juste après que le kernel affiche les messages :
      VP_IDE: VIA vt8283... UDE UDM100 controller....
      ide0 : .... hda:DMA, hdb:DMA
      ide1 : .... hdc:DMA, hdd:DMA
      hda : TRANSCEND, ATA DISK driver
      ...
      hdd : blabla DVDROM

      et avant le montage des partitions ? (c'est là que ça déconne) :
      EXT3-fs: mounted filesystem with ordered data mode.
      hda: dma_intr: status=0x51 { DriverReady SeekComplete Error }
      hda: dma_intr: error=0x84 { DriverStatusError BadCRC }
      hda: dma_intr: status=0x51 { DriverReady SeekComplete Error }
      hda: dma_intr: error=0x84 { DriverStatusError BadCRC }
      idem
      ...
      ...
      hdb : DMA disabled (le DMA est activé au boot là, donc pourquoi il touche à hdb qui est le disque dur normal)
      ide0: reset: success
      • [^] # Re: hdparm

        Posté par  . Évalué à 1.

        Voici d'autres tests :


        * boot avec : ide=nodma nodma

        test de copie de fichier de HDD à CF : 2,7Mo/s et 2,6Mo/s
        action du DMA avec hdparm (hdparm -d1 /dev/hda et hdb) : 18,5Mo/s et 19,8Mo/s)

        peut après (suite à un 'hdparm -i /dev/hdb' peut être), plantage de la console
        => delogué, erreurs DMA (timeout), ext3-fs error, etc.


        * boot avec ide=nodma, disque dur avec dma activé (hdparm), CF sans DMA :
        Le système a l'air stable, sauf que la CF est sous vraiment utilisée (5ou6Mo/s en lecture).

        Dois-je en conclure d'après vous que c'est l'adaptateur le fautif ?
        • [^] # Re: hdparm

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

          J'ai aussi ce système et j'ai du recompiler le noyau en désactivant l'option DMA pour le boot ( j'avais précisé ça dans l'autre post ). En fait cela vient du noyau visiblement plus que du contrôleur ( dans mon cas l'option nodma au boot ne suffisait pas ).

          Pour ce qui est du nombre de cycles, il s'agit du nombre d'écriture PAR secteur ! ( Le nombre de lectures est infini ! ) Ce qui rend tout de suite la chose plus intéressante ( il suffit de déplacer certains logs et certains répertoires de /var sur tmpfs et il n'y a plus aucun problèmes : la carte peut passer une journée à tournée sans qu'on y aille écrire quoi que ce soit...
          ( par exemple mettre en tempfs /tmp /var/log/ntpstats, /var/lib/ntp, /var/cache/ddclient et supprimer syslog[-ng] devrait déjà suffire )

          Le gros avantage est de pouvoir mettre le disque dur en stand-by à ce moment là, et de ne le laisser s'activer que lorsque l'on a besoin d'accéder à des données ( /home par exemple ).
          -> baisse de la consommation, baisse de la température ( le fanless devient possible )

          À ce propos on peut trouver sur ebay de nombreux PC barebones ( aux alentours de 266-533Mhz ) qui ont un slot CF intégré sur la carte mère...

          Dans mon cas il ne me reste plus qu'à mettre en place un script init qui irait copier certains fichiers dans /tmp et qui ensuite irait les sauvegarder sur le disque dur au moment où on éteint le pc avant de considérer que mon installation est complète.
          • [^] # Re: hdparm

            Posté par  . Évalué à 1.

            Ca signifie donc que ta carte n'est pas à son débit maximum ?
            Quelles sont les performances cependant ?
            Est-ce que le lancement des applications est + réactif quand même ?


            Je ne compte pas la faire tourner à 5mo/s au lieu de 40mo/s... je vais aller me renseigner du coté du vendeur du convertisseur (le constructeur a l'air chinois lui : mini doc en anglais et en chinois).
            • [^] # Re: hdparm

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

              Effectivement, le débit sur la carte est très faible :

              $ sudo hdparm -tT /dev/hdc

              /dev/hdc:
              Timing cached reads: 122 MB in 2.02 seconds = 60.38 MB/sec
              Timing buffered disk reads: 8 MB in 3.70 seconds = 2.16 MB/sec

              Les applications restent réactives ( enfin pour un serveur ! il n'y a pas X dessus, juste ssh, apache, exim... ) donc pour ce que j'en fait tout cela fonctionne très bien pour moi.. ).
              En fait le débit ne me dérange pas plus que ça, ce qui compte pour moi c'est la fiabilité de la carte, et le fait que je puisse complètement désactiver mon autre disque dur, et donc laisser le pc se faire oublier dans un coin... ( je ne me sers donc pas de ce pc comme ordinateur principal ). Comme il passe la plupart du temps à ne rien faire, autant qu'il se mette en veille, qu'il ne consomme pas, mais qu'il puisse s'activer à la moindre demande.

              Enfin renseigne toi, sûrement que d'un matériel à l'autre, les résultats seront différents...
          • [^] # Re: hdparm

            Posté par  . Évalué à 2.

            Après avoir mis à jour de Sarge (la seule à ma disposition ce soir) à Testing, cela ne marche plu...
            - Kernel 2.6.8 => 2.6.18 (et c bien lui le responsable, car ça boot sans soucis avec le 2.6.8, ou alors c'est un programme lié comme Hal (qui a besoin d'un 2.6.15 pour se lancer)).

            Bref... c'est pas simple...
            • [^] # Re: hdparm

              Posté par  . Évalué à 1.

              J'ai réussi à passer le boot sans devoir toucher au kernel avec les options "ide=nodma noapic".
              Il y a des erreurs au boot, cependant ça passe quand même, et une fois le boot terminé je peux voir que le DMA est bien désactivé.
              Je suppose donc que le kernel ne prend en compte l'option nodma qu'à partir d'un certain moment.

              Une fois booté, j'ai testé différentes options avec le DMA, et ce qui donne les meilleurs performances est le mode 'mdma2' :
              # hdparm -d1 -Xmdma2 -tT /dev/hda
              Timing buffered disk reads: 44 MB in 3.08 seconds = 14.30 MB/sec
              # hdparm -d1 -Xudma1 -tT /dev/hda
              Timing buffered disk reads: 24 MB in 3.22 seconds = 7.44 MB/sec
              Les autres modes > udma1 provoquent des erreurs DMA.

              J'ai trouvé sur cette page [1] une liste des correspondances entre les modes ultra DMA et les normes ATA. Pour mon adapteur qui supporte du ATA33, celà correspond au umda2. Mon adaptateur est éventuellement menteur dans sa doc :D

              J'ai aussi constaté un autre problème, sûrement lié à la désactivation du DMA au boot, même après l'activation avec hdparm : le CPU tourne à 100% lors d'une copie de fichier, et pendant plus longtemps que la copie.
              Ex pour un fichier de 170Mo :
              #time cp fichier_hdb fichier_hda
              réel : 0m7.561s
              et temps CPU : 18s à 100%
              Il faut donc se méfier des benchs (vous avez déjà entendu ça qq part non ? :p) et le mode udma1 n'est pas plus lent si on tient compte du CPU.

              chimrod > si tu as encore le noyau qui plante, peut-tu tester avec l' option 'noapic' en + voir si ça boot chez toi ?

              nicO > en effet, en modifiant le mode avec hdparm il y a eu du progrès, même si on est très loin des 40Mo/s :p

              [1] http://gentoo-wiki.com/HOWTO_Use_hdparm_to_improve_IDE_devic(...)
              • [^] # Re: hdparm

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

                Je te conseillerais de faire les essaies avec le tout dernier noyau et avec les lspci et autre qui vont bien et mettre le tout dans le système de correction de bugsde linux.

                "La première sécurité est la liberté"

              • [^] # Re: hdparm

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

                Merci pour l'info !

                J'ai donc testé le boot avec noapic, et ça me permet d'avoir le dma sur le DD ( pas sur la carte CF, j'ai des erreurs DMA au démarrage, mais qui se terminent sur un DMA désactivé ) Je vais pouvoir revenir au noyau standard !
                ( J'avais fait mes premiers test avec un pentium1, pour qui le passage par la recompilation est obligatoire.. )

                Pour info, pour identifier quels sont les programmes qui pourraient éventuellement écrire sur la carte ( pour éviter les points d'usure ), lancer sysctl vm.block_dump=1 et ensuite vérifier avec dmesg quels sont les programmes ayant écrit sur les disques..

                Il y a sûrement moyen de faire un bon tuto de tout ça, à partir des différentes config, et des différentes expériences...!
              • [^] # Re: hdparm

                Posté par  . Évalué à 1.

                Je vais peut être dire un connerie mais de mémoire il me semble
                que pour du DMA33 il faut une nappe 40 pin et non pas 80 comme
                pour UDMA66, 100 et 133.

                Donc essaye si tu peux avec uniquement la compact flash sur une nappe 40.
  • # dommage de ne pas pouvoir plusser un tel journal

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

    Pour tout dire, je pensais moi aussi à faire ce genre de tests, mais je n'ai pas encore eu le temps.

    :-)

    ウィズコロナ

  • # 1 million d'écritures

    Posté par  . Évalué à 3.

    Ce qui me fait toujours peur avec cette technologie, c'est cette limite de 1 million d'écritures (oui je suis au courant que ce n'est pas exactement un million, mais c'est de cet ordre de grandeur).

    Je ne connais pas les chiffres pour les disques durs, mais ca me semble quand même très faible, non ? Et en fin de vie ça se comporte comment ? Ça arrête de fonctionner tout d'un coup ? Ou bien ça laisse un petite chance de récupérer ses données ?
    • [^] # Re: 1 million d'écritures

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

      Les bons controleurs savent gérer ça très bien. Ils gardent des blocs libres, invalident ceux qui posent problème, etc. Il y a même parfois des algos pour éviter que l'écriture ne se fasse toujours au même endroit, et des FS qui utilisent des index d'index d'index pour être sûr que les manipulations sur le FS ne fassent pas trop d'écriture toujours au même endroit.
      Bref, normalement c'est assez bien géré si tu n'utilises pas le support pour tes fichiers temporaires ou pour écrire des logs à gogo.
      • [^] # Re: 1 million d'écritures

        Posté par  . Évalué à 5.

        Les bons controleurs savent gérer ça très bien


        En scsi, oui, en ata, non...

        Le mieux pour éviter les problèmes, c'est utiliser la flash en read only tant que faire se peut et désactiver la mise à jour des atime dans les filesystems accessibles en écriture (ok, c'est une entorse au standard posix, mais ça économise la flash qui sinon est écrite à chaque accès en lecture)
        • [^] # Re: 1 million d'écritures

          Posté par  . Évalué à 1.

          Bon, je veux bien qu'on moinsse, mais un argument serait vraiment intéressant si j'ai quelque-chose de faux... allez, soyez pas timides...

          (bon de préférence des remarques valables de personnes ayant fait de vrais systèmes embarqué...)
        • [^] # Re: 1 million d'écritures

          Posté par  . Évalué à 2.

          Je plussoie fortement la désactivation de l'atime.
          J'ai rencontré le problème sur un système embarqué utilisant JFFS2 pour de la flash : je n'écrivais rien sur la flash mais pourtant, je voyais que l'on y accédait en écriture (et ça consommait plein de RAM). Jusqu'à ce que je m'aperçoive que ça venait de la mise à jour de l'atime sur tous les fichiers accédés en lecture...
        • [^] # Re: 1 million d'écritures

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

          C'est le contrôleur coté flash qui gère ça pas du coté IO

          "La première sécurité est la liberté"

          • [^] # Re: 1 million d'écritures

            Posté par  . Évalué à 2.

            Mwais, si tu parles du contrôleur à l'intérieur de la carte Compact Flash, comment reconnaître les bons contrôleurs des mauvais?

            Parceque bon, le coup du yakaavoirunboncontrôleurflash, c'est difficile à mettre en ½uvre dans le monde réel, et il vaut mieux avoir de bonnes pratiques au niveau de la gestion des écritures dès la configuration de l'OS plutôt que de se reposer sur une hypothétique qualité de la carte flash.
  • # durée de vie

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

    Le problème n'est-il pas sur la durée de vie des CP?
    Combien de cycles d'écritures?
    • [^] # Re: durée de vie

      Posté par  . Évalué à 2.

      Ca monte à 1 million sur cette carte.

      Par contre je ne sais pas si :
      - c'est pour 1 million de lecture et ecriture au total ou séparement
      - c'est 1 million/block ou octet ou s'ils utilisent une technique de répartition des données pour éviter d'ecrire trop souvent au même endroit (ce qui pourrait amener à 10 000 écritures réelles par block ou octet)

      Quoiqu'il en soit il faut :
      - utiliser l'option noatime (pour desactiver l'ecriture de la date de dernier accès aux fichiers)
      - parametrer la valeur de /proc/sys/vm/swappiness pour réduire la quantité d'écritures sur disque (60 par défaut, de 10 à 30 selon les préférences des internautes :p)
      • [^] # Re: durée de vie

        Posté par  . Évalué à 4.

        Par contre je ne sais pas si :
        - c'est pour 1 million de lecture et ecriture au total ou séparement
        - c'est 1 million/block ou octet ou s'ils utilisent une technique de répartition des données pour éviter d'ecrire trop souvent au même endroit (ce qui pourrait amener à 10 000 écritures réelles par block ou octet)

        En interne tu as souvent des memoires nand + un µcontrolleur :
        - c'est 1 million en écriture, les lectures impactant peu
        - le µcontrolleur répartie l'usure des secteurs, mais vu qu'il n'a pas la connaissance de ce que veux faire le filesystem c'est pas toujours génial (voir ca peut etre catastrophique sur certains fs).

        Donc oui, il faut limiter au maximun les écritures à la fois au niveau fichier mais aussi au niveau fs (noatime, pas un fs qui a besoin de réécrire toute les métadata (FAT, ...) à chaque modif, ...).

        Le top étant d'avoir un "/" en ro, un "/tmp", "/var/log", ... en RAM et une partition rw pour les données user.
        • [^] # Re: durée de vie

          Posté par  . Évalué à 2.

          1 million d'écritures... C'est énorme. Je crois que la durée de vie d'un tel disque est supérieure aux disque durs pour servers.

          (mais ça marche pas pour les clés USB qui n'ont que 10.000 écritures je crois)
  • # de la flash intégrée à un disque dur

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

    J'ai entandu de par un ami qui ne jure que par Windows que devrait sortir des ordinateurs avec un disque dur hybride contenant de la flash pour accélérer le boot de Windows.

    Ca a l'air intéressant ... en savez-vous un peu plus ? C'est vrai que ca peut être intéressant sachant que les donées systèmes ne changent pratiquement jamais.
    • [^] # Re: de la flash intégrée à un disque dur

      Posté par  . Évalué à 1.

      L'idée de la flash pour accélérer le boot est sympa (c'est en partie le but de mon installation). Le lancement des programmes est aussi plus rapide.

      Par contre, la mettre dans le disque dur est une mauvaise idée selon moi (ça a cependant l'avantage de charger + rapidement depuis le disque), car :
      - tu ne peux pas changer la taille de la flash comme tu veux (ca m'étonnerait que ça soit amovible :D)
      - si ça tombe en panne t'es niqué
      - faut espérer que le protocol soit standardisé et non breteté de partout
    • [^] # Re: de la flash intégrée à un disque dur

      Posté par  . Évalué à 5.

      Cette techno est juste un pis aller.

      Dans environ 2 ans les HDD classique seront mort (sauf pour les grosse capacité) et on aura que des disques flash.

      Autant attendre un peu et acheter directement un HDD flash, bien plus performant.

      Je conseille à tous cet article complet sur les technos SSD:

      http://www.presence-pc.com/tests/ssd-flash-disques-22675/
      • [^] # Re: de la flash intégrée à un disque dur

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

        Dans environ 2 ans les HDD classique seront mort (sauf pour les grosse capacité) et on aura que des disques flash.


        Attends un peu que la vidéo HD se généralise... par exemple, si tu veux enregistrer un épisode de série télévisée de 45 minutes sur ton ordinateur, ça va te prendre 6 Go. A ce rythme, même les disques durs les plus spacieux montrent leurs limites... alors ne parlons même pas de la mémoire Flash.
        • [^] # Re: de la flash intégrée à un disque dur

          Posté par  . Évalué à 5.

          Note quand même que tu n'auras pas le droit d'enregistrer cet épisode en vidéo HD.

          DADVSI cheval de Troie des fabricants de flash ?

          La gent féminine, pas la "gente", pas de "e" ! La gent féminine ! Et ça se prononce comme "gens". Pas "jante".

        • [^] # Re: de la flash intégrée à un disque dur

          Posté par  . Évalué à 2.

          Attends un peu que la vidéo HD se généralise... par exemple, si tu veux enregistrer un épisode de série télévisée de 45 minutes sur ton ordinateur, ça va te prendre 6 Go


          D'ici là, la nouvelle version du standard DVB sera là avec son "broadcast flag" pour t'empêcher de gaspiller de l'espace disque avec de la vidéo HD...
    • [^] # Re: de la flash intégrée à un disque dur

      Posté par  . Évalué à 1.

    • [^] # Re: de la flash intégrée à un disque dur

      Posté par  . Évalué à 2.

      Microsoft ne fabrique pas de disques durs ou d'ordinateurs (à part à des fins de prototypage).

      Les unités de stockage hybrides flash+disque sont le résultat de l'intégration des deux technologies par les constructeurs de disque en réaction aux fonctions ReadyBoost et Superfetch déjà présentes dans Vista: ces fonctions ont pour but de construire et d'utiliser des caches sur flash permettant d'accélérer le démarrage de la machine en réduisant le temps d'accès.

Suivre le flux des commentaires

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