Forum Linux.debian/ubuntu Reshape mdadm très lent de RAID5 de 3 à 4 disques

Posté par  (site web personnel, Mastodon) . Licence CC By‑SA.
Étiquettes :
2
9
sept.
2020

Sommaire

Hello les moules,

Sur un serveur de récupération que j'utilise depuis quelques mois en homeserver/NAS avec grande satisfaction (HP Microserver N40L équipé d'un CPU AMD Turion et 4 Go de RAM), j'ai ajouté il y a quelques jours le "dernier" disque de la grappe que je souhaitais mettre en place : 4x 4 To en soft-RAID5 afin d'avoir 12 To à peu près sûrs afin d'y stocker des backups, principalement.

La machine tournait avec 3x 4 To en soft-RAID5 depuis plusieurs mois et je n'avais aucun problème de perfs à signaler, bien que je ne lui en demandais pas trop. Je ne sais par contre pas exactement quelles étaient ces perfs précisément en terme de débit sur le périphérique /dev/md0.

Une fois le disque ajouté, j'ai lancé la procédure pour intégrer ce disque à la grappe, et qui s'appelle apparemment le reshape. Aucun problème à signaler, le processus s'est bien lancé.

Mais j'ai été ébaubi par l'estimation du temps restant, directement lié au débit observé : environ 30 jours, pour un débit de 1 Mo/s au mieux.

Voici l'état actuel à ce jour, sachant que j'ai lancé le process dimanche dernier, il y a 3 jours :

Personalities : [raid6] [raid5] [raid4] [linear] [multipath] [raid0] [raid1] [raid10]
md0 : active raid5 sdd[4] sda[0] sdc[3] sdb[1]
      7813775152 blocks super 1.2 level 5, 8k chunk, algorithm 2 [4/4] [UUUU]
      [=>...................]  reshape =  6.8% (267783332/3906887576) finish=55060.9min speed=1101K/sec
      bitmap: 2/30 pages [8KB], 65536KB chunk

unused devices: <none>

Et encore là c'est revenu à un débit "presque acceptable" en étant au dessus du Mo/s, car il a passé la journée du lundi à 650 ko/s de moyenne.

J'ai suivi les conseils mentionnés sur cette page, notamment

  • /sys/block/*/device/queue_depth
  • /sys/block/md0/md/sync_max
  • blockdev --setra /dev/md0 65536

mais sans résultat probant.

J'ai testé la vitesse de lecture avec hdparm -Tt et j'obtiens bien des débits bruts en cache de ~1000 Mo/s et ~100 Mo/s hors-cache.

J'en arrive à la conclusion que le problème vient certainement de la taille des chunks qui est de 8 ko ce qui est très petit, et augmente logiquement fortement les I/O.

Cette taille n'était pas un choix éclairé de ma part car je passe (passais) pour la gestion "NAS" du serveur par OpenMediaVault, et j'avais à l'origine créé un RAID1 avec 1 disque (temporaire) qui a ensuite été progressivement évolué vers un RAID1 avec 2 disques, puis un RAID5 avec 3 disques, et enfin aujourd'hui sa configuration finale en RAID5 à 4 disques. Je suppose qu'il aurait été pertinent de modifier la taille des chunks dès le passage au RAID5, et mettre une valeur plus commune comme 128 ou 512 ko.

Qu'en pensez-vous ? Une dernière piste à explorer avant de patienter encore 4 semaines pour retrouver ma grappe finalisée ? :)

Quelques informations complémentaires ci-dessous.

# mdadm --detail /dev/md0
/dev/md0:
           Version : 1.2
     Creation Time : Thu Oct 11 18:42:58 2018
        Raid Level : raid5
        Array Size : 7813775152 (7451.80 GiB 8001.31 GB)
     Used Dev Size : 3906887576 (3725.90 GiB 4000.65 GB)
      Raid Devices : 4
     Total Devices : 4
       Persistence : Superblock is persistent

     Intent Bitmap : Internal

       Update Time : Thu Sep 10 13:30:07 2020
             State : active, reshaping 
    Active Devices : 4
   Working Devices : 4
    Failed Devices : 0
     Spare Devices : 0

            Layout : left-symmetric
        Chunk Size : 8K

Consistency Policy : bitmap

    Reshape Status : 9% complete
     Delta Devices : 1, (3->4)

              Name : sihaya:volume1
              UUID : 9e9abda8:006e7462:bd4bde5d:b6401408
            Events : 120780

    Number   Major   Minor   RaidDevice State
       0       8        0        0      active sync   /dev/sda
       1       8       16        1      active sync   /dev/sdb
       3       8       32        2      active sync   /dev/sdc
       4       8       48        3      active sync   /dev/sdd

# fdisk -l
Disque /dev/sda : 3,7 TiB, 4000787030016 octets, 7814037168 secteurs
Modèle de disque : WDC WD40EZRZ-00G
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets

Disque /dev/sdb : 3,7 TiB, 4000787030016 octets, 7814037168 secteurs
Modèle de disque : ST4000DM004-2CV1
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets

Disque /dev/sdc : 3,7 TiB, 4000787030016 octets, 7814037168 secteurs
Modèle de disque : WDC WD40EZRZ-00G
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets

Disque /dev/sdd : 3,7 TiB, 4000787030016 octets, 7814037168 secteurs
Modèle de disque : ST4000VX007-2DT1
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets

# iostat -k 1 2
Linux 4.19.0-10-amd64 (sihaya)  09/09/2020  _x86_64_    (2 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3,39    1,24    3,66   69,29    0,00   22,42

Device             tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda              72,17      1488,08      1016,40  414346320  283009386
sdc              92,64      1488,01      1016,33  414326433  282990430
sdb              71,79      1487,77      1016,31  414259612  282983970
sdd              84,82         2,53       987,87     703817  275066004
sde               7,82        12,08        79,95    3363708   22260254
md0               3,26        48,09        57,54   13389093   16020672

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0,51    0,00    7,14   92,35    0,00    0,00

Device             tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda              65,00      4696,00      1600,00       4696       1600
sdc              78,00      4696,00      1608,00       4696       1608
sdb              61,00      4712,00      1564,00       4712       1564
sdd              73,00         0,00       784,00          0        784
sde               0,00         0,00         0,00          0          0
md0               2,00         8,00         0,00          8          0


# dstat -af
--total-cpu-usage-- --dsk/sda-----dsk/sdb-----dsk/sdc-----dsk/sdd-----dsk/sde-- net/br-866f-net/docker0--net/enp2s0---net/tun0- ---paging-- ---system--
usr sys idl wai stl| read  writ: read  writ: read  writ: read  writ: read  writ| recv  send: recv  send: recv  send: recv  send|  in   out | int   csw 
  4   8   0  89   0|   0  1712k:4096B 1692k:   0  1708k:   0  1712k:   0     0 |   0     0 :   0     0 :   0     0 :   0     0 |   0     0 |1203  1339 
  3   4   0  94   0|   0  2052k:   0  2016k:   0  2056k:   0  2052k:   0    36k|   0     0 :   0     0 : 282k   37k:   0     0 |   0     0 |1408  1484 
  0   2   0  98   0|   0  2336k:   0  2272k:   0  2208k:   0  2336k:   0     0 |   0     0 :   0     0 : 142k   35k:   0     0 |   0     0 | 873   764 
  2   3   0  95   0|   0  1624k:   0  1688k:   0  1688k:   0  1560k:   0     0 |   0     0 :   0     0 : 133k   14k:   0     0 |   0     0 |1073  1304 
  3   4   0  94   0|   0  1740k:   0  1744k:   0  1804k:   0  1804k:   0     0 |   0     0 :   0     0 : 129k   24k:   0     0 |   0     0 |1032   997 
  1   2   0  97   0|   0  1488k:   0  1544k:   0  1484k:   0  1484k:   0     0 |   0     0 :   0     0 : 155k   23k:   0     0 |   0     0 |1056  1132 
  2   3   0  95   0|4096B 1392k:   0  1332k:   0  1332k:   0  1396k:   0    40k|   0     0 :   0     0 : 137k   15k:   0     0 |   0     0 | 896   833 
  2   3   0  95   0|   0  1712k:   0  1712k:   0  1708k:   0  1700k:   0     0 |   0     0 :   0     0 : 122k   21k:   0     0 |   0     0 |1373  1375 
 15  19   0  66   0|  36M 1045k:  36M 1041k:  36M 1029k:8192B  933k:   0     0 |   0     0 :   0     0 : 140k   20k:   0     0 |   0     0 |1911  4876 
 35  12   0  53   0| 833k  896k: 828k  896k: 828k  896k:   0   952k:   0    56k|   0     0 :   0     0 :  76k   36k:   0     0 |   0     0 |1769  2032 
  7  10   0  83   0| 772k  856k: 768k  912k: 768k  920k:   0   860k:   0     0 |   0     0 :   0     0 : 247k   31k:   0     0 |   0     0 |1668  2468 
  4  12   0  84   0| 128k 1744k: 128k 1744k: 128k 1620k:   0  1736k:   0    12k|   0     0 :   0     0 : 121k   29k:   0     0 |   0     0 |

Mise à jour 12/09/2020

Après activation du cache writeback sur les disques et un retour à une valeur de NCQ de 32, le débit s'est stabilisé à ~26 Mo/s ce qui a permis de terminer l'opération de reshape en 2 jours seulement. La possibilité de modifier la taille des chunks et la passer à 64 voire 128 ko est encore en étude.

  • # Accès aléatoire

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

    Tu satures tes disques en IOPS (environ 75 i/o par seconde en moyenne pour des disques magnétiques 7200 tours/minute) car tu fais des accès aléatoires (non séquentiels). Les accès aléatoires sont vraiment l'énorme différence de perf entre les SSD et les disques magnétiques.
    hdparm -tT c'est un test en accès séquentiel donc pas représentatif si tu fais de l'aléatoire.
    En effet si tu peux augmenter la taille des blocs de données accédés à chaque i/o, tu devrais pouvoir augmenter ton débit.

    • [^] # Re: Accès aléatoire

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

      En effet ça semble logique. Mais où vois-tu cette valeur de ~75 IOPS dans les sorties des commandes ? Je suis curieux je n'y vois que des valeurs en ko/s.

      Je ne sais pas comment faire pour augmenter la quantité de données lues à chaque "tour", je pensais que la commande blockdev --setra servait à ça, mais apparemment mdadm ne semble pas trop y voir de différence.

      Si j'avais une solution qui impliquait d'augmenter sensiblement la RAM occupée pour ce travail (en travaillant sur de plus gros lots de données) ça ne me dérangerait pas, j'ai encore presque 3 Go libres, mais je ne trouve rien qui permette ça.

  • # CPU ?

    Posté par  . Évalué à 3.

    Intuitivement, je mettrais ça sur le dos du Turion et ses perfs en calcul de checksum. Il me semble que c'est plutôt du bas de gamme mais je peux me tromper.

    Ici, le bench que fait mon kernel à chaque démarrage donne ça :

    raid6: sse2x1 gen() 6491 MB/s
    raid6: sse2x1 xor() 5016 MB/s
    raid6: sse2x2 gen() 7808 MB/s
    raid6: sse2x2 xor() 5965 MB/s
    raid6: sse2x4 gen() 8893 MB/s
    raid6: sse2x4 xor() 6532 MB/s
    raid6: using algorithm sse2x4 gen() 8893 MB/s
    raid6: .... xor() 6532 MB/s, rmw enabled
    raid6: using ssse3x2 recovery algorithm
    xor: measuring software checksum speed
    prefetch64-sse: 11104.000 MB/sec
    generic_sse: 9623.000 MB/sec
    xor: using function: prefetch64-sse (11104.000 MB/sec)

    Et ton Turion ?

    • [^] # Re: CPU ?

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

      J'y ai pensé aussi, mais quand je regarde le load je vois surtout beaucoup d'iowait et pas beaucoup de temps kernel ou user (80% d'iowait contre 10% max de kernel+user). À mon sens ça devrait pourtant se traduire par une occupation forte de ces états.

      La sortie de mon dmesg :

      [    4.470732] raid6: sse2x1   gen()  2107 MB/s
[    4.538717] raid6: sse2x1   xor()  2003 MB/s
[    4.606728] raid6: sse2x2   gen()  3375 MB/s
[    4.674719] raid6: sse2x2   xor()  3409 MB/s
[    4.742733] raid6: sse2x4   gen()  4054 MB/s
[    4.810714] raid6: sse2x4   xor()  2175 MB/s
[    4.810717] raid6: using algorithm sse2x4 gen() 4054 MB/s
[    4.810718] raid6: .... xor() 2175 MB/s, rmw enabled
[    4.810720] raid6: using intx1 recovery algorithm

      Pas top certes, mais pas trop dégueu non plus je pense, non ?

      • [^] # Re: CPU ?

        Posté par  . Évalué à 3.

        Yep, ça n'est "que" deux fois plus lent qu'ici.
        Le check d'un RAID 5 sur 3 x 10 To prend environ 16 heures chez moi.
        Peut-être un peu plus à la construction initiale, mais je ne me rappelle plus. Pas beaucoup plus, ça c'est certain.
        Ça n'explique pas le délai annoncé chez, et de très loin.

        Est-ce que le mode de fonctionnement des disques est bon ? Je parle du SATA 6 Gbps, 3 Gbps ou moins. Mais aussi les modes les plus vieux comme UDMA.
        J'ai déjà eu des pépins de disques correctement reconnus au boot. Et puis quelques heures/jours/mois plus tard, il se passe un truc que je n'ai jamais compris, et paf, message dans les logs et très souvent, grosse perte de performance. Quelque chose comme ça.

        Jamais compris. Seagate est une partie de l'explication. Mais Western Digital n'a pas tout réglé.

        • [^] # Re: CPU ?

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

          Quand j'ai vu ces perfs j'ai cherché une explication dans les logs, et notamment des erreurs SATA (par expérience…). Mais là rien du tout, les logs systèmes sont cleans, rien à redire.

          Si le problème était lié au débit es interfaces, je pense que les tests hdparm l'auraient révélé.

          Quelle est la taille des chunks sur ta grappe ?

          • [^] # Re: CPU ?

            Posté par  . Évalué à 1.

            512k :

            Personalities : [raid6] [raid5] [raid4] [linear] [multipath] [raid0] [raid1] [raid10] 
md0 : active raid5 sdb3[1] sdc3[3] sda3[0]
      19385805824 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
      bitmap: 5/73 pages [20KB], 65536KB chunk

            • [^] # Re: CPU ?

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

              Ouais je crois que c'est ce qui fait toute la différence ici. Il faudrait (aurait fallu) que j'augmente la taille des chunks en passant du RAID1 à RAID5.

              A priori c'est possible de le faire a posteriori, mais encore faut-il que le reshape se termine d'abord…

              (et j'imagine que cette action va aussi prendre des plombes pour les mêmes raisons)

  • # Quelques réglages que j'utilise

    Posté par  (site web personnel) . Évalué à 3. Dernière modification le 10 septembre 2020 à 12:00.

    • internal bitmap

    mdadm -G /dev/md0 -binternal

    je ne sais plus pourquoi, mais c'est plus rapide sur un md-raid5.

    • activer le writecache (au moins le temps du rebuild/reshape)

    sdparm -s WCE=1 /dev/sd[a-d]

    • enlarge les caches et les buffers

    echo "500000" > /proc/sys/dev/raid/speed_limit_max # déjà fait ?
    echo 1024 > /sys/block/$disk/queue/read_ahead_kb # from 128 to 8192
    echo 256 > /sys/block/$disk/queue/nr_requests # from 128 to 8192
    blockdev --setra 16384 /dev/$disk # déjà fait ?
    blockdev --setra 65536 /dev/$mdisk # déjà fait.
    echo 16384 > /sys/block/$mdisk/md/stripe_cache_size
    echo 8192 > /sys/block/$mdisk/md/stripe_cache_active

    avec $disk = sda, sdb… et $mdisk = md0. Si le /sys/block/$disk/queue/scheduler existe, le passer en cfq.

    • installer 'irqbalance' (qui devrait être installé pour de qqchose qui fait de l'I/O)

    Proverbe Alien : Sauvez la terre ? Mangez des humains !

    • [^] # Re: Quelques réglages que j'utilise

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

      Très juste, j'avais oublié de mettre la sortie de mdadm --detail /dev/md0, j'ai corrigé ça.

      Normalement ça permet de dire que j'utilise déjà un internal bitmap. C'est bien le but de ta première commande ?

      Pour les commandes suivantes voici l'état actuel :

      # cat /proc/sys/dev/raid/speed_limit_max
200000

# cat /sys/block/sd[a-d]/queue/read_ahead_kb
128
128
128
128

# cat /sys/block/sd[a-d]/queue/nr_requests
64
64
64
64

# for dev in $(echo /dev/sd[a-d]); do echo -n "$dev: "; blockdev --getra $dev; done
/dev/sda: 256
/dev/sdb: 256
/dev/sdc: 256
/dev/sdd: 256

# blockdev --getra /dev/md0
65536

# cat /sys/block/md0/md/stripe_cache_size
8192

# cat /sys/block/md0/md/stripe_cache_active
12041

      Bon clairement y'a des choses à ajuster. Je m'en vais tenter ça de suite. Merci !

      Autres sources trouvées à ce sujet en passant, avec des valeurs égales ou similaires :
      - https://wtf.roflcopter.fr/links/pogo/?nICtQw
      - http://wiki.alessandro.delgallo.net/wiki/index.php/RAID

      • [^] # Re: Quelques réglages que j'utilise

        Posté par  (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 10 septembre 2020 à 14:04.

        Bon, après 5mn pas de changement notable malgré les "optimisations" apportées :(

        Je déconseille par contre fortement dans une situation similaire de suivre les conseils indiquant qu'il faut désactiver le NCQ sur les disques : en faisant ça le débit a chuté chez moi en 1mn à ~500 ko/s ! (j'avais déjà testé ça en début de semaine avec le même résultat)

      • [^] # Re: Quelques réglages que j'utilise

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

        C'est bien le but de ta première commande ?

        Oui. Mais je n'arrive pas à remettre la main sur la ref disant qu'une "internal bitmap" c'est plus rapide qu'une "external bitmap".

        Le 'raid/speed_limit_max', entre 200k et 500k, ça change pas grand chose… de toute façon, on touche aux limites du bus sata.

        Pour 'read_ahead_kb', 'nr_requests' et 'blockdev --setra', je gagne a les augmenter, par device, même sur du sata.

        Et le truc qui sauve vraiment, c'est le write cache des disques. C'est souvent désactivé par défaut parce qu'en cas de coupure brusque, ça fait de gros dégats dans le FS. Mais ça accélère vraiment sur des I/O un peu intenses.

        Proverbe Alien : Sauvez la terre ? Mangez des humains !

        • [^] # Re: Quelques réglages que j'utilise

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

          Et le truc qui sauve vraiment, c'est le write cache des disques. C'est souvent désactivé par défaut parce qu'en cas de coupure brusque, ça fait de gros dégats dans le FS. Mais ça accélère vraiment sur des I/O un peu intenses.

          Ah oué c'est radical oO

          Je passe instantanément (ok non en quelques minutes) à 18 Mo/s.

          Le serveur étant sur un onduleur avec 30mn d'autonomie et une extinction automatique propre on va dire que c'est plutôt safe. Dans tous les cas, c'est principalement des backups donc pas de question de vie ou de mort en cas de perte des données.

          Merci !

          • [^] # Re: Quelques réglages que j'utilise

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

            Ah, et passer /sys/block/$dev/device/queue_depth de 8 à 16 permet de gagner encore 5 Mo/s (soit environ 23 Mo/s).

            Je l'avais abaissé à 8 en supposant qu'il s'agissait d'un bon compromis entre 1 (les conseils lus à droite et à gauche) et 32, la valeur par défaut.

            Le repasser à 32 m'a encore permis de remonter à 27 Mo/s. Je comprends vraiment pas ces conseils.

            • [^] # Re: Quelques réglages que j'utilise

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

              C'est lié aux accès aléatoires et au NCQ.

              Dans le pire des cas chaque accès prend un maximum de temps à cause de sa position sur le disque (par exemple si tu lis un bloc juste avant).

              Le principe du NCQ est de ré-ordonnancer les accès dans la file d'attente, pour minimiser le parcours du disque à effectuer.

              Donc par exemple si tu demandes à lire quelque chose comme ça et que les blocs sont stockés dans l'ordre sur le disque (je mets les numéros de blocs):

              5 - 4 - 3 - 2

              À chaque fois tu dois attendre un tour complet du disque vu que le bloc à lire suivant est situé avant celui qui vient d'être lu.

              Avec NCQ, le contrôleur du disque va réordonnancer la liste des requêtes à effectuer afin de minimiser la distance à parcourir sur le disque:

              2 - 3 - 4 - 5

              Au final le temps de réponse pour la première requête est plus important, mais le débit global est augmenté.

              NCQ ne peut agir que sur les requêtes envoyées au disque (donc fonction de la taille de la file d'attente).

              Donc plus tu augmentes la taille de la file de requête plus potentiellement NCQ peut augmenter le débit en réordonnançant des requêtes, au détriment de la latence des requêtes situées au début de la file.

              • [^] # Re: Quelques réglages que j'utilise

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

                Oui pardon, j'avais bien compris le principe du NCQ pour les disques et de sa pertinence pour améliorer les perfs, mais presque tous les articles que j'ai vus qui parlaient de solutions concernant la lenteur d'un reshape de RAID5 disaient de le désactiver (càd de passer à 1).

                Or chez moi ça a exactement l'effet inverse et baisse considérablement les débits. Alors que le laisser à 32 permet de revenir à des performances acceptables.

                • [^] # Re: Quelques réglages que j'utilise

                  Posté par  . Évalué à 7.

                  Ça peut être un conseil pertinent si le RAID ne fait que son reshape, parce qu'il va le faire séquentiellement.

                  Mais si le périphérique est en cours d'utilisation (les FS sont montés et utilisés par des programmes), alors tu va avoir des accès aléatoire qui vont venir s'ajouter à ce beau processus séquentiel, ce qui va te massacrer les performances.

  • # CMR/SMR

    Posté par  . Évalué à 6.

    Hum, d'après ce que je vois, tu as deux disque Western Digital et un Seagate SkyHawk qui utilisent la technologie CMR, et un Seagate Barracuda qui utilise technologie SMR.

    Plusieurs constructeurs se sont fait récemment choppé à vendre des disque SMR sans que ce soit vraiment annoncé.

    Je ne maitrise pas vraiment le sujet, mais pour résumer cette vidéo, le problème est que SMR "superpose" des données, permettant une plus grande densité, mais requiert de réécrire toutes les données superposées à chaque écriture.

    Normalement, du cache est là pour que ces écritures se fassent lorsque le disque est idle, mais lors d'un rebuild, ou tu vas écrire en permanence, il ce peut que le disque ne s'en sorte pas bien (cf Synology).

    La vidéo fait notamment mention d'un problème avec le RaidZ de FreeNas, ou un rebuild de disque CMR prend 16h tandis qu'avec un disque SMR, cela prend 9+ jours.

    Toujours chez Synology :

    En raison des caractéristiques des performances des disques SMR, ce modèle est uniquement adapté aux environnements de charges de travail légères. Une dégradation des performances peut survenir dans le cadre d'opérations d'écriture continues.

    • [^] # Re: CMR/SMR

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

      C'est effectivement une très bonne remarque. Cette idée m'avait traversé l'esprit mais j'ai pensé que c'était plutôt réservé à des HDD de plus grosses capacités, en oubliant que justement les constructeurs s'étaient fait pincer récemment à omettre ces informations sciemment sur certains modèles…

      Merci pour les docs, effectivement c'est une erreur de ma part en choisissant les disques. J'ai un peu trop joué sur le côté Inexpensive du RAID en prenant des disques d'entrée de gamme. Je note de remplacer le Barracuda qui n'est pas adapté à l'usage.

    • [^] # Re: CMR/SMR

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

      et pour approfondir, PMR / CMR / SMR :
      https://en.wikipedia.org/wiki/Perpendicular_recording PMR / CMR
      https://en.wikipedia.org/wiki/Shingled_magnetic_recording SMR

      (sur wikipedia anglais c'est un peu plus complet que sur la page en français, qui est plutôt une synthèse)

Suivre le flux des commentaires

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