dimanche 20 juillet
April | Agenda du libre | Framasoft | Léa-Linux | Lolix | JeSuisLibre | Eyrolles | LinuxMag | Veni, Vidi, Libri | InLibroVeritas | LinuxGraphic
Faire un don ! | | style | statistiques | contactez-nous | plan | lettre d'information
Accueil :: Dépêches :: Archives :: Proposer une dépêche :: Journaux :: Forums :: Entretiens :: Suivi :: RDF

Journal : remplacer un disque dur par une compact flash

Posté par dark_star () le 16 mai 2007
cher journal
j'utilise depuis 1 mois environ une carte compactflash dans un de mes portables (734.03 BogoMIPS) depuis ce changement, il est devenu vraiment silencieux, il n'y a aucun défaut sauf parfois la souris se bloque 1 seconde de temps en temps pendant un accés disque. C'est une carte de 2Go sandisk simple (pas ultra, ni II, ni III, ni IV), mes besoin sous linux sont simple et 2Go avec xfce cela suffit amplement. (CF=compact flash)

Depuis 2 ans 3 disques dur mon laché, c'est pourquoi avec la mise en vente d'adaptateur flash/2,5' je me suis lancé. le souci principal c'est que l'adaptateur c'est bien gentil mais cela ne rentre pas dans un caddie, il n'ont pas eu l'idée (l'argent ?) pour au moins reprendre les dimmension d'un disque dur 2,5'. de plus il a fallu casser une broche pour pouvoir l'inserer (détrompeur sur le connecteur femelle), et démonter intégralement le laptop pour accéder au connecteur. Bref ce n'est helas pas super ami de l'utilisateur.

Je pourrais mettre certaine partie en lecture seul mais bon, autant faire un essai réel histoire de voir les ragots 'tu vas la griller' se confirmer. j'ai même mis du swap dessus. Pour mémoire une CF de 2Go coûte 10 a 20 euro. C'est tellement concluant que pour mon autre laptop (3000.26 BogoMIPS) je compte l'equiper avec une compact flash de 8Go (actuellement j'utilise 5Go sur 60Go, jeux, latex etc...)

Je commence à mettre sur des postes fixes une CF de 2Go en plus du disque dur avec grub dessus et xfce et 2 choix: linux, secours comme cela si le disque dur lâche, mes parents/amis peuvent demarrer sur la CF en attendant mon arrivé. Avec la certitude que la CF n'auras pas de problème. Et si le cas se présente il est plus facile de changer une CF qu'un disque dur pour une personne non informaticienne


information du dmesg
hda: SanDisk SDCFB-2048, CFA DISK drive
hda: 4001760 sectors (2048 MB) w/1KiB Cache, CHS=3970/16/63, DMA
hda: hda1 hda2 < hda5 >



df -h
/dev/hda1 1,7G 1,2G 438M 74% /



hdparm -t /dev/hda
/dev/hda:
Timing buffered disk reads: 32 MB in 3.12 seconds = 10.25 MB/sec

hdparm -T /dev/hda
/dev/hda:
Timing cached reads: 396 MB in 2.00 seconds = 197.62 MB/sec



hdparm -i /dev/hda

/dev/hda:

Model=SanDisk SDCFB-2048, FwRev=HDX 3.17, SerialNo=116908B2206T2921
Config={ HardSect NotMFM Removeable DTR>10Mbs nonMagnetic }
RawCHS=3970/16/63, TrkSize=0, SectSize=576, ECCbytes=4
BuffType=DualPort, BuffSize=1kB, MaxMultSect=4, MultSect=off
CurCHS=3970/16/63, CurSects=4001760, LBA=yes, LBAsects=4001760
IORDY=no, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 *mdma2
AdvancedPM=no
Drive conforms to: Unspecified: ATA/ATAPI-4

* signifies the current active mode


voila voila

> Lire le journal (59 commentaires, moyenne: 3).  

Vous avez demandé le commentaire #832547.

Limitations ?

Posté par Nor Yarod () le 16/05/2007 à 07:43. (lien). Évalué à 5.

L'idée est bonne, mais un doute Masaï (je -> [])
La CF n'est-elle pas fort limitée en terme de cycle de lecture / écriture ?
Ne risque-t-elle pas de devenir rapidement (quelques mois) inutilisable ?

  • [^]Re: Limitations ?

    Posté par Jerome Herman () le 16/05/2007 à 07:56. (lien). Évalué à 6.

    Malheureusement si. A moins de se priver totalement du swap, du journaling et de toute forme de cache disque, il y a des risques réels de collectionner les "bad blocks" après quelques mois.

    En fait les mémoires flash supportent entre 10 000 et 100 000 réécritures par block (les plus anciennes tiennent plutôt de l'ordre de 2000/3000). Les systèmes de fichiers *nix sont donc très agressifs sur de la cache, encore plus quand ils sont journalisés. Le réarangement en continu des inodes et la défragmentation n'aident pas vraiment...

    En fait il est tout à fait possible d'utiliser un disque flash dans un système à condition de réduire au maximum les accès disques (par exemple en ayant un système qui ne bouge pas trop et qui se monte en RAMFS). A part çà je ne prendrais pas le risque personellement.

    --
    Kha
    root est un privilège, pas un droit !

    • [^]Re: Limitations ?

      Posté par Nelis (page perso, ) le 16/05/2007 à 08:13. (lien). Évalué à 4.

      Est-ce qu'il y aurait moyen d'avoir un système qui boot sur une mémoire flash (l'os + les programmes sont dessus) et qui utilise un HD pour le swap et les données (ce qui normalement est le plus souvent modifié).

      Ca devrait permettre d'avoir le meilleur des deux mondes : un chargement rapide, plus de volumes pour les données, et un système un peu plus silencieux.

      --
      Vache qui rit, à moitié dans son lit

      • [^]Re: Limitations ?

        Posté par Sébastien Koechlin () le 16/05/2007 à 08:29. (lien). Évalué à 2.

        Sur un portable, il est généralement difficile de mettre deux disques dur.

        Sur mon serveur, depuis plusieurs années j'ai mis le /boot sur une CF, non pas pour augmenter la vitesse, cela ne fait pas de différence; mais pour augmenter la fiabilité.

        Les choses vont peut-être changer avec les nouveaux PC et le support par Vista d'une mémoire Flash complémentaire au disque dur. Ca devrait se démocratiser dans le matériel vendu.

        Ca donne ça (c'est une vieille carte de 32 Mo):


        hda: PQI ATA Rev6.0, CFA DISK drive
        hda: 64000 sectors (32 MB) w/0KiB Cache, CHS=1000/16/4

        hdparm -t /dev/hda
        /dev/hda:
        Timing buffered disk reads: 6 MB in 3.66 seconds = 1.64 MB/sec

        Model=PQI ATA Rev6.0, FwRev=XS3.00, SerialNo=PQI0000000000
        Config={ HardSect NotMFM Removeable DTR>10Mbs nonMagnetic }
        RawCHS=1000/16/4, TrkSize=8448, SectSize=528, ECCbytes=4
        BuffType=1Sect, BuffSize=0kB, MaxMultSect=1, MultSect=off
        CurCHS=1000/16/4, CurSects=64000, LBA=yes, LBAsects=64000
        IORDY=no
        PIO modes: pio0 pio1
        AdvancedPM=no

        [^]Re: Limitations ?

        Posté par liberforce (Jabber id, page perso, ) le 16/05/2007 à 08:37. (lien). Évalué à 2.

        Il y a aussi moyen de régler le kernel pour utiliser au maximum la RAM et au minimum le swap. Voir /proc/sys/vm/swappiness.

        • [^]Re: Limitations ?

          Posté par ccomb (Jabber id, page perso, ) le 16/05/2007 à 08:57. (lien). Évalué à 4.

          notamment le laptop-mode permet de reposer le disque dur. J'en avait assez de voir la diode du disque s'allumer systématiquement toutes les 2 ou 3 secondes, et après avoir activé le leptop-mode, il n'y a plus aucun accès. Ca doit être important en cas de comact flash.

          • [^]Re: Limitations ?

            Posté par MrLapinot (Jabber id, page perso, ) le 16/05/2007 à 15:10. (lien). Évalué à 1.

            De mémoire, ce sont dans ce cas les écritures qui sont bufferisées et exécutées par bloc toutes les x minutes ; ça permet l'augmenter l'autonomie parce que ça laisse le disque en veille dans l'intervalle, mais ça risque de ne pas changer grand chose au nombre de secteurs écrits.

            --
            Mr Lapinot - Electrons prisonniers (blog)

    [^]Re: Limitations ?

    Posté par Sébastien Koechlin () le 16/05/2007 à 08:12. (lien). Évalué à 3.

    Comme la FAT règne en maître sur le secteur des cartes mémoire, ces problèmes de vieillissement prématuré de certaines cellules (celles de la table d'allocation justement) ont été critique dès le début. A chaque fois que l'on modifie le nombre de secteur d'un fichier, la FAT est ré-écrite.

    Les fabriquants ont été obligé d'installer dans leurs cartes une couche d'indirection entre les secteurs logiques vus par le système et les secteurs logiques. Ainsi, si on écrit 100 fois le même secteur, ce n'est pas le même secteur physique qui est utilisé à chaque fois.

    Bien sur, ça coute, et dans le bas de gamme, on trouve encore probablement des mémoires qui n'implémentent pas ce genre de chose.

    • [^]Re: Limitations ?

      Posté par Nelis (page perso, ) le 16/05/2007 à 08:16. (lien). Évalué à 2.

      Et il n'est pas possible de formatter une carte avec un autre système de fichier ?

      --
      Vache qui rit, à moitié dans son lit

      • [^]Re: Limitations ?

        Posté par dawar (page perso, ) le 16/05/2007 à 08:24. (lien). Évalué à 1.

        Ben si, c'est ce qu'a fait l'auteur du journal (je pense pas que son GNU/Linux tourne sur de la FAT). Mais dans les appareils photo, lecteurs mp3, etc, c'est FAT qui est utilisée, et si on formate dans un autre format, l'engin ne peut plus lire la carte.

        • [^]Re: Limitations ?

          Posté par Nelis (page perso, ) le 16/05/2007 à 08:32. (lien). Évalué à 2.

          Oui ok c'est ce qui me semblait. Si on utilise la carte comme disque dur, à la limite on s'en fiche que l'appareil photo ne la lise plus, dans le pire des cas on reformatte en FAT.

          --
          Vache qui rit, à moitié dans son lit

          [^]Re: Limitations ?

          Posté par dark_star () le 16/05/2007 à 08:37. (lien). Évalué à 4.

          oui c'est vrai j'ai longtemps hesité pour le systeme de fichier, finalement j'ai pris du ext3 avec l'option noatime dans /etc/fstab pour ne pas trop exagerer sur les ecritures.

          • [^]Re: Limitations ?

            Posté par alenvers () le 16/05/2007 à 08:55. (lien). Évalué à 7.

            Il est bon aussi de monter quelques répertoire en tmpfs genre les logs et fichier tmp. Chez moi :

            tmpfs 20M 11M 9.7M 52% /var/log
            tmpfs 20M 11M 9.7M 52% /var/run
            tmpfs 20M 11M 9.7M 52% /var/lib
            tmpfs 20M 11M 9.7M 52% /var/lock
            tmpfs 20M 11M 9.7M 52% /var/tmp
            +
            tmpfs 1.0M 0 1.0M 0% /var/cache/bind
            tmpfs 1.0M 4.0K 1020K 1% /var/cache/ddclient

            C'est un peu chiant pour les logs qui sont perdus au reboot mais bon, il est possible de synchroniser ceux-ci de façon périodique vers la flash et de les reloader au reboot.


            Il est cool également de faire un lien symbolique de /etc/mtab -> /proc/mounts afin d'éviter des écriture intempestives.

            De mémoire, c'est à peu près tout ce qui est nécessaire. Sinon pour un système où les installatation de programmes sont assez rare faire une image compressée cloop (read-only) peut-être un bon plan niveau économie d'espace. Chez moi (Image de 70Mo compressée) :

            dev/cloop0 237M 158M 79M 67% /bin
            dev/cloop0 237M 158M 79M 67% /lib
            dev/cloop0 237M 158M 79M 67% /sbin
            dev/cloop0 237M 158M 79M 67% /usr
            dev/cloop0 237M 158M 79M 67% /var

            Quand j'ai besoin d'un nouveau logiciel je regénére l'image sur mon autre machine.

        [^]Re: Limitations ?

        Posté par alenvers () le 16/05/2007 à 08:24. (lien). Évalué à 2.

        Tu mets ce que tu veux c'est un bête device IDE. Mais la majorité des CF sont en fat (app. photo num, etc.).

      [^]Re: Limitations ?

      Posté par Camille Vacher () le 16/05/2007 à 08:38. (lien). Évalué à 2.

      J'avais lu dans un vieux Linux Mag le témoignage d'une personne ayant installé un linux sur une CF pour faire fonctionner un robot. Il évoquait un système de fichier spécialement concu pour les CF, qui écrivait les blocks de facon plus ou moins aléatoire pour éviter justement de réécrire trop de fois au même endroit. Quelqu'un en a-t'il entendu parlé ? Des liens, des infos ?

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.0791s (dont 0.0084 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.