• # hdparm

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

    La partition est elle sur un autre disque ? Si oui tu peux peutêtre lancer hdparm sur le disque en question pour verifier certains paramètres soient bien activés (using_dma à 1, IO_support ...).
    hdparm /dev/hdX

    • [^] # Re: hdparm

      Posté par  . Évalué à 1.

      Alors, voici le résultat des commandes passées:

      [prompt]#hdparm /dev/hda1
      /dev/hda1:
      multcount = 0 (off)
      IO_support = 0 (default 16-bit)
      unmaskirq = 0 (off)
      using_dma = 1 (on)
      keepsettings = 0 (off)
      readonly = 0 (off)
      readahead = 256 (on)
      geometry = 16383/255/63, sectors = 55293777, start = 63

      Donc, IO_support n'est pas activé.

      [prompt]#hdparm -c1 /dev/hda1
      /dev/hda1:
      setting 32-bit IO_support flag to 1
      HDIO_SET_32BIT failed: Invalid argument
      IO_support = 0 (default 16-bit)

      Ca marche pas beaucoup mieux, j'ai un peu cherché mais je n'ai pas trouvé de solutions à mon problème.

      Pour info:

      [prompt]#hdparm -tT /dev/hda1
      /dev/hda1:
      Timing cached reads: 800 MB in 2.00 seconds = 400.13 MB/sec
      Timing buffered disk reads: 78 MB in 3.04 seconds = 25.68 MB/sec


      [prompt]#hdparm -I /dev/hda1
      /dev/hda1:

      ATA device, with non-removable media
      Model Number: IC25N040ATMR04-0
      Serial Number: MRG257K2CJBDDJ
      Firmware Revision: MO2OAD0A
      Standards:
      Used: ATA/ATAPI-6 T13 1410D revision 3a
      Supported: 6 5 4
      Configuration:
      Logical max current
      cylinders 16383 65535
      heads 16 1
      sectors/track 63 63
      --
      CHS current addressable sectors: 4128705
      LBA user addressable sectors: 78140160
      LBA48 user addressable sectors: 78140160
      device size with M = 1024*1024: 38154 MBytes
      device size with M = 1000*1000: 40007 MBytes (40 GB)
      Capabilities:
      LBA, IORDY(can be disabled)
      Standby timer values: spec'd by Vendor, no device specific minimum
      R/W multiple sector transfer: Max = 16 Current = 0
      Advanced power management level: 128 (0x80)
      Recommended acoustic management value: 128, current value: 254
      DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
      Cycle time: min=120ns recommended=120ns
      PIO: pio0 pio1 pio2 pio3 pio4
      Cycle time: no flow control=240ns 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
      * Advanced Power Management feature set
      Power-Up In Standby feature set
      * SET_FEATURES required to spinup after power up
      Address Offset Reserved Area Boot
      SET_MAX security extension
      Automatic Acoustic Management feature set
      * 48-bit Address feature set
      * Device Configuration Overlay feature set
      * Mandatory FLUSH_CACHE
      * FLUSH_CACHE_EXT
      * SMART error logging
      * SMART self-test
      * General Purpose Logging feature set
      Security:
      Master password revision code = 65534
      supported
      not enabled
      not locked
      frozen
      not expired: security count
      not supported: enhanced erase
      34min for SECURITY ERASE UNIT.
      HW reset results:
      CBLID- above Vih
      Device num = 0 determined by the jumper
      Checksum: correct

      • [^] # Re: hdparm

        Posté par  . Évalué à 1.

        Avoir using_dma = 1 (on) est suffisant, le paramètre IO_Support ne joue pas beaucoup à ma connaissance (voire pas du tout).
        De plus, le résultat du test de lecture de hdparm me semble tout à fait honorable : Timing buffered disk reads: 78 MB in 3.04 seconds = 25.68 MB/sec. Donc ce n'est pas l'accès brut à ton disque qui pose problème, ça doit être au-dessus (le système de fichiers, peut-être).

  • # no

    Posté par  . Évalué à 1.

    J'ai une vistesse qui monte jusqu'a 12mo/s sur fat32 depuis gunlinux. tu doit avoir un probleme sur ton disque. est il defectueux? hyperfragmenter?

    • [^] # Re: no

      Posté par  . Évalué à 1.

      Non, il n'est pas défectueux et au niveau défragmentation, ca va...
      Je pense qu'il s'agit plus d'un problème du coté configuration

  • # Questions subsidiaires

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

    Tes 2 partitions sont-elles sur le même disque?
    As-tu les mêmes temps entre 2 partitions linux?
    As-tu les mêmes temps dans l'autre sens?
    Combien as-tu de mémoire disponible?

    Garde à l'esprit que dans tous les cas, mv se contente de répéter autant de fois qu'il le faut les 4 opérations :
    - placement de la tête sur le fichier d'origine (mettons 8ms sur un bon disque)
    - lecture d'un bloc (attendre au moins 1 tour de disque, soit 8ms sur un 7200 tr/mn. Pour des petits blocs, on peut négliger le temps de transfert)
    - placement de la tête sur le fichier destination (encore 8ms!)
    - écriture du bloc (et encore 8ms!)
    Si ton système a moyen de choisir une grande taille de blocs, ça va très vite. Mais si tu tombes à une taille de bloc de 10k, fais le calcul, ça fait 30000 fois 32ms, soit 16 minutes.

    Si tu veux jouer un peu, fais ta copie avec dd if=<fichier source> of=<fichier destination> bs=<taille des blocs en octets>, et fais des essais en changeant la taille des blocs! :)

    • [^] # Re: Questions subsidiaires

      Posté par  . Évalué à 3.

      C'est intéressant :)

      Mais pourquoi il prend pas tout le fichier en un ou deux blocs ?
      Y'a des risques de corruption quand y'a trop à copier d'un coup ?

    • [^] # Re: Questions subsidiaires

      Posté par  . Évalué à 1.

      Alors, mes partitions sont sur le même disque.
      Avec ta méthode, ca marche beaucoup mieux. J'ai modifié la taille des blocs et ca va beaucoup plus vite.
      Par contre, j'aurai aimé savoir comment faire pour connaître la taille de mes blocs.
      J'ai fait un df mais j'aurai aimé savoir s'il y avait une autre manière.

    • [^] # Re: Questions subsidiaires

      Posté par  . Évalué à 3.

      mv se contente de répéter autant de fois qu'il le faut les 4 opérations : [..] lecture d'un bloc

      heu, si chaque fichier était vraiment lu bloc par bloc (et avec l'attente d'un tour), le système serait très lent. D'une part la commande mv (tout comme cp) lit plusieurs blocs d'un coup, et d'autre part le disque et le système font du pre-fetch / read-ahead pour accélérer les opérations, précisément pour améliorer une éventuelle lecture bloc par bloc.

      Mes copies ou déplacements de fichiers (avec cp ou mv) se font toujours à peu près à la vitesse nominale du disque. L'utilisation d'un dd n'accélère rien chez moi.

      • [^] # Re: Questions subsidiaires

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

        Les "blocs" dont je parlais ne sont pas les blocs physiques (4k je crois) mais des portions du fichier que le système peut loger dans sa mémoire libre (dans les "cached" et "buffers" de la commande free). L'idée du dd, c'était juste pour forcer l'allocation de mémoire (quitte à swapper un processus qui dort).
        Je pensais aussi au cas d'un système destination monté avec l'option "sync". Dans ce cas, chaque écriture est faite en live, sans cache. Ca pourrait bien pourrir les temps de copie. Mais je crois que cette option n'est pas disponible pour le fat32...

    • [^] # Re: Questions subsidiaires

      Posté par  . Évalué à 1.

      J'oubliais de dire que parmi ces 4 opérations, les 2 dernières ne sont pas effectuées à chaque fois, et de très loin, puisque l'écriture (qui demande éventuellement un déplacement de la tête) n'est faite qu'en mémoire dans un premier temps, dans le cache du noyau. C'est au bout du délai de synchronisation (5 s par défaut) ou quand le cache est plein qu'il est "flushé" sur le disque d'un coup (lors du sync). Ca se voit sur une grosse copie, le voyant du disque clignote fortement sur la lecture, puis toutes les 5 secondes il devient complètement allumé pendant un certain temps, lors du "sync".

Suivre le flux des commentaires

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