Forum général.cherche-matériel Les SSDs

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes : aucune
-51
28
juil.
2011

Bon... c'est pas tout ça... Pas mal d'entre vous ont essayé les SSD... y'a du pour et du contre...

http://linuxfr.org/users/nedflanders/journaux/les-ssd

OK, d'accord... Concrètement, j'ai de l'argent à perdre. J'achète quoi ?

D'après vos retours, votre expérience personnelle :
Crucial ? Intel ?
Quel FS mettre dessus ?

Auto-motivation financière : ne pas craquer, le giga est trop cher, c'est pas fiable, ça se flashe mal sous linux, faut le flasher toutes les semaines...

  • # et hop

    Posté par  (Mastodon) . Évalué à 2.

    purée -50, fatche ce score !

    J'achète quoi ?

    ben je sais pas. et fort probable qu'on soit nombreux comme ça.

    Crucial ? Intel ?

    trop cher, bien trop cher, pour une machine personnelle type latop. SSD Intel c'est bon pour le matos professionnel et les serveurs. Voilà ce que je me suis dit.

    Quel FS mettre dessus ?

    BtrFS Sans hésiter.
    après on peut pinailler sur des fonctionnalités avec LogFS ou même jffs. Mais bon, vu tout ce que fait le firmware, on peut pinailler aussi à dire que logfs ne sert malheureusement à rien sur du ssd moderne.

    Concrètement, j'ai de l'argent à perdre.

    ben Intel alors.

    Perso j'ai profité d'une promo sur les vertex2 de OCZ, 100GO à 120 euros.
    C'est certes plus cher qu'un hd à plateaux, mais je préfère faire l'impasse sur des gadgets pour profiter d'un bon disque dur. L'offre 100go à 120 euros reste quant même une très bonne affaire d'après ce que j'ai compris.

    Après, sur les Vertex2 on peut lire tout et son contraire. Donc le mieux est certainement de le bourriner d'entrée, illico. Configuration choisie, propre et neuve, mise à jour firmware, puis tests de suspend to disk, en mode normal et en mode brutal (avec une swap déjà occupée). ensuite test de pertes d'alimentation. Si ça casse -> sav. Si ça passe (comme ici) -> ok

    A noter que OCZ fournit un binaire 32 et un binaire 64 pour linux pour la mise à jour de son firmware. A noter aussi que ce binaire n'est pas indispensable, on peut utiliser flashrom, le support de ces ssd ayant été intégré, donc OCZ doit au minimum (en plus de fournir les binaires à eux) "doc-é" et ça c'est bien.

    ocz vertex2, donné pour
    lecture = 285MB/s
    écriture = 275MB/s
    Vérifié. c'est fulgurant. Seul le fait d'effacer avec l'outil rm est "lent"

    ps : j'ai hésité à faire un lien magique vers hardware.fr mais bien que la blague soit drôle, tu ne l'aurais peut être pas appréciée, donc, bon...

    • [^] # Re: et hop

      Posté par  (Mastodon) . Évalué à 2.

      correction pour flashrom :
      ce n'est pas flashrom, mais le kit firmware

      et j'profite de la correction pour une photo :

      photo inutile

      bref les SSD c'est bon :-)

      • [^] # Re: et hop

        Posté par  (Mastodon) . Évalué à 2.

        pour continuer sur ce modèle de ssd, voici les infos renvoyées, grâce à hdparm

        ATA device, with non-removable media
        Model Number:       OCZ-VERTEX2                             
        Serial Number:      OCZ-B3YMI482YBKNY6P3
        Firmware Revision:  1.33    
        Transport:          Serial
Standards:
        Used: unknown (minor revision code 0x0028) 
        Supported: 8 7 6 5 
        Likely used: 8
Configuration:
        Logical         max     current
        cylinders       16383   16383
        heads           16      16
        sectors/track   63      63
        --
        CHS current addressable sectors:   16514064
        LBA    user addressable sectors:  195371568
        LBA48  user addressable sectors:  195371568
        Logical  Sector size:                   512 bytes
        Physical Sector size:                   512 bytes
        Logical Sector-0 offset:                  0 bytes
        device size with M = 1024*1024:       95396 MBytes
        device size with M = 1000*1000:      100030 MBytes (100 GB)
        cache/buffer size  = unknown
        Nominal Media Rotation Rate: Solid State Device
Capabilities:
        LBA, IORDY(can be disabled)
        Queue depth: 32
        Standby timer values: spec'd by Standard, no device specific minimum
        R/W multiple sector transfer: Max = 16  Current = 1
        DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 
             Cycle time: min=120ns recommended=120ns
        PIO: pio0 pio1 pio2 pio3 pio4 
             Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features:
        Enabled Supported:
           *    SMART feature set
                Security Mode feature set
           *    Power Management feature set
           *    Write cache
           *    Look-ahead
                Host Protected Area feature set
           *    WRITE_BUFFER command
           *    READ_BUFFER command
           *    NOP cmd
           *    DOWNLOAD_MICROCODE
                SET_MAX security extension
           *    48-bit Address feature set
           *    Mandatory FLUSH_CACHE
           *    FLUSH_CACHE_EXT
           *    SMART error logging
           *    SMART self-test
           *    General Purpose Logging feature set
           *    WRITE_{DMA|MULTIPLE}_FUA_EXT
           *    64-bit World wide name
           *    IDLE_IMMEDIATE with UNLOAD
           *    WRITE_UNCORRECTABLE_EXT command
           *    Segmented DOWNLOAD_MICROCODE
           *    Gen1 signaling speed (1.5Gb/s)
           *    Gen2 signaling speed (3.0Gb/s)
           *    Native Command Queueing (NCQ)
           *    Host-initiated interface power management
           *    Phy event counters
           *    DMA Setup Auto-Activate optimization
                Device-initiated interface power management
           *    Software settings preservation
           *    SMART Command Transport (SCT) feature set
           *    SCT LBA Segment Access (AC2)
           *    SCT Error Recovery Control (AC3)
           *    SCT Features Control (AC4)
           *    SCT Data Tables (AC5)
           *    Data Set Management TRIM supported (limit 1 block)
           *    Deterministic read data after TRIM
Security: 
                supported
        not     enabled
        not     locked
        not     frozen
        not     expired: security count
                supported: enhanced erase
        400min for SECURITY ERASE UNIT. 400min for ENHANCED SECURITY ERASE UNIT.
Logical Unit WWN Device Identifier: 5e83ablabla
        NAA             : 5
        IEEE OUI        : e83ablabla
        Unique ID       : f9fbblabla
Checksum: correct
[root@hpg72 linux64]#

        À noter que la valeur 400mn pour SecureErase est une fausse valeur. Le 'flushage' est instantané (en fait un reset pour revenir à des banques vides)

        Tests simples (time sur dd) de performances :
        D'abord avec une création de petit poids :

        125000+0 enregistrements lus
125000+0 enregistrements écrits
1024000000 octets (1,0 GB) copiés, 3,43155 s, 298 MB/s

real    0m3.439s
user    0m0.023s
sys     0m1.063s

        Ici sur un effacement, avec l'outil RM, d'un fichier de 15GB :

        14618+0 enregistrements lus
14618+0 enregistrements écrits
15328083968 octets (15 GB) copiés, 57,4001 s, 267 MB/s

        On voit la différence entre une écriture basique et l'utilisation de rm, ressentie par ailleurs et confirmé ici : l'effacement de fichiers (avec rm) est "plus lent". M'enfin ça tape bien les valeurs données sur la boiboite :-)

        Conclusion personnelle : je suis enchanté de mon modèle de Vertex2 de chez OCZ ...

        • [^] # Re: et hop

          Posté par  (Mastodon) . Évalué à 2.

          arf viandage de copier/coller, désolé (pas encore bu mon café matinal), le second test ne concerne donc pas le rm mais la création du fichier (de 15go) pour le rm... Qui lui est réalisé en real 0m0.715s

          • [^] # Re: et hop

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

            Ces timings sont merveilleux mais testent beaucoup plus l'efficacité de la RAM (et du buffer) que du disque dur.

            • [^] # Re: et hop

              Posté par  (Mastodon) . Évalué à 2.

              Pour le rm, certainement, oui, merci de la remarque.


              time dd if=/dev/zero of=ddout bs=8k count=125000 && sync

              C'est bourrin, oui.

              Un autre résultat de test, par exemple avec bonnie :

              bonnie++

              Un autre exemple, avec fs_mark en mode "fait chuter les débits" : création de 10 000 fichiers de 8k, dans chacun des 1000 sous-répertoires, écriture en mode synchrone...

              ``
              fs_mark -D 1000 -N 100 -n 10000 -s 8 -L 1 -S 1 -d ~/fsmark/ -t 10

              FSUse% Count Size Files/sec App Overhead
              64 100000 8 2116.3 3470568
              ``

        • [^] # Re: et hop

          Posté par  . Évalué à 3.

          Tes test montres que tu arrives à saturation du SATA2 (3Gbps = 300 Mo/s).

          Vivement les SDD en SATA3... pas trop chers.

          • [^] # Re: et hop

            Posté par  (Mastodon) . Évalué à 2.

            un bug dans la matrice ?

            hey!

            • [^] # Re: et hop

              Posté par  . Évalué à 3.

              Je me demande si c'est de l'humour ou pas :-)

              $ time sleep 1 && sleep 10

real    0m1.002s
user    0m0.000s
sys     0m0.000s


              $ time (sleep 1; sleep 10)

real    0m11.004s
user    0m0.000s
sys     0m0.004s

              • [^] # Re: et hop

                Posté par  (Mastodon) . Évalué à 2.

                atta j'te la refais en vidéo

                http://www.youtube.com/watch?v=pTUdJHmQEEI

              • [^] # Re: et hop

                Posté par  (Mastodon) . Évalué à 2.

                la précédente n'étant pas pertinente, en voici une autre, où on tu peux vérifier que l'écriture se fait bien sur le disque dur, et où je m'amuse aussi avec ta remarque :-) ... (donc, question : mais où le truc ?)

                http://www.youtube.com/watch?v=NgyDbXCyBFc

                • [^] # Re: et hop

                  Posté par  (Mastodon) . Évalué à 2.

                  par contre il n'y a pas de malice dans la question : je ne sais vraiment pas pourquoi cela renvoi de telles valeurs. Qui me semble impossible (voir ta remarque sur le lien sata2)

                  • [^] # Re: et hop

                    Posté par  . Évalué à 2.

                    Tu as bien le bon résultat. Ce n'est pas dd qui te le donne (puisqu'avant le sync), mais time: 0,724 seconde pour 102 Mo, soit 141 Mo/s.

                    Sinon il ne servirait à rien de lancer time :-)

Suivre le flux des commentaires

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