Après une (courte) accalmie, la course à la capacité reprend dans le monde des disques dur. Western Digital proposera prochainement les premiers échantillons de son Ultrastar DC HC550 de 18 To, mais aussi de l'Ultrastar DC HC650 de 20 To (SMR). La production de masse sera lancée début 2020.
Actuellement, les disques durs de 3,5" avec la plus grande capacité affichent 16 To. C'est le cas des Exos X16 et IronWolf (Pro) de Seagate, mais aussi du MG08 de Toshiba ; tous avec neuf plateaux. Pour le moment, personne n'avait sauté le pas des 18 To, du moins jusqu'à l'annonce de Western Digital.
Ultrastar DC HC550 : un modèle « classique » de 18 To
Commençons par l'Ultrastar DC HC550, le nouveau venu dans la série des Ultrastar DC HC500. Après les versions de 10 To (HC510), 12 To (HC520) et 14 To (HC530), la gamme va donc passer à 18 To. On remarque que le fabricant s'est laissé de la place pour un HC540 de 16 To qui pourrait arriver ultérieurement.
Toute la série dispose de la sixième génération de la technologie HelioSeal qui consiste à remplacer l'air entre les plateaux par de l'hélium. Ils sont au nombre de neuf dans le cas du HD550. Malheureusement, Western Digital ne dit pas un mot sur ses performances ou son prix.
L'Ultrastar DC HC650 grimpe à 20 To, mais il faut un contrôleur compatible
Vient ensuite l'Ultrastar DC HC650 de 20 To, qui se placera au-dessus de l'actuel HC620 de 15 To. Attention, malgré la proximité des noms entre les séries HC500 et HC600, il existe une différence fondamentale : la première exploite un enregistrement des données classique CMR/PMR (Classic/Perpendicular Magnetic Recording), tandis que la seconde passe au SMR (Shingled Magnetic Recording).
Pour rappel, cette technique consiste à légèrement superposer les pistes les unes avec les autres afin d'augmenter la densité (lire nos explications). Elle induit par contre une problématique : lors de l'écriture, il faut réinscrire les données des pistes se chevauchant, entraînant un phénomène d'amplification en écriture.
Pour profiter d'un disque dur SMR, il faut donc que le contrôleur ou le disque dur prennent en charge cette technologie. Il existe trois manières d'y arriver : host managed, drive managed et host aware, dans ce dernier cas, le disque dur peut décider de le faire lui-même ou de déléguer l'opération au contrôleur.
Actuellement, les disques durs sont host managed, et c'est le cas de la série Ultrastart DC HC600 de Western Digital, comme indiqué dans ce document. N'espérez donc pas installer ce HDD de 20 To dans votre ordinateur ou NAS, il faudra qu'il dispose d'un contrôleur spécifique capable de prendre en charge le SMR.
Comme la série HC500, neuf plateaux sont présents, avec de l'hélium entre eux (technologie HelioSeal). Là encore, nous n'avons aucun détail concernant les performances ou le tarif.
Des échantillons cette année, la production en masse début 2020
Les premiers échantillons de disques durs Ultrastar DC HC550 (18 To, CMR) et Ultrastar DC HC650 (20 To, SMR) arriveront d'ici la fin de l'année pour des clients triés sur le volet. Nul doute que la réponse de ses concurrents ne devrait pas tarder à se manifester avec eux aussi des capacités de 18 et 20 To.
La production en masse débutera à partir de la première moitié de 2020. Western Digital mise beaucoup sur la technologie SMR et pense que 50 % des disques durs qu'il expédiera en 2023 seront en SMR.
Pour rappel, Western Digital et Seagate se livrent également une bataille sur des technologies du futur pour dépasser allégrement la barrière des 20 To et arriver à 40 To en 2023/2025. Elle prend le nom de MAMR (Microwave-Assisted Magnetic Recording) chez Western Digital et HAMR (Heat-assisted magnetic recording) chez Seagate.
Commentaires (29)
#1
Les disques de 4To que j’ai vont sembler bien petits dans quelques années
Quand je repense à l’époque où mon DD système faisait 2Go (et semblait bien large)…
#2
Un ordre de prix ? Par rapport aux SSD de même capacité ?
#3
Je ne comprends pas ces modèles de disques dont le contrôleur ne fait pas tout le boulot (“Ultrastar DC HC650 grimpe à 20 To, mais il faut un contrôleur compatible”). Tous les autres, on les connecte sur un port SAS ou SATA et ça fonctionne.
#4
Ça va surement piquer.
Et tient en parlant de NAS, il en est ou le dossier sur les NAS?
#5
Quand je pense mon premier DD qui faisait 20Mo
et qui avait couté les 2 reins … 
Bon d’accord je suis un vieux crouton et c’était y’a 30 ans …
Quand au 18To, ca va être chaud de motiver le boss pour changer la baie chez nous.
#6
C’est décrit la raison dans l’article. Mais pour faire simple, ce DD ont déjà un but très spécifique : l’archivage de donnée. Tu fais une archive, tu branche ce dd, tu écris la sauvegarde dessus, tu débranche et tu le conserves dans une étagère avec une dizaines/centaines d’autre.
Dans cet usage d’archive, la donnée est écrite d’une seul traite et il n’est pas prévu que les fichiers soit réécrit entre temps. Cependant, la densité d’écriture est importante, il faut maximiser la quantité de données. C’est là qu’intervient la propriété des disque dur SMR qui permet justement de maximiser la densité d’écriture au prix de la difficulté de réécrire là où il y a déjà des truc écrit en contact direct.
D’après ce que je comprends, les HC650 sont uniquement host managed, c’est a dire que ce travail de réécriture n’est pas réalisé par le DD lui même, il faut le commander pour qu’il le fasse. Cependant, WD semble avoir prévu dans le futur de proposer des DD SMR avec drive managed ou host aware qui feront d’eux même ce travail de réécriture (optionnel pour host aware) et pourrait potentiellement donc être utilisé comme un DD classique (suaf qu’il aura de piètre performance).
#7
Merci pour l’explication, mais je trouve quand même ça pas pratique même si on l’utilise pour de l’archivage pur.
Après tout, les SSD aussi doivent réécrire les blocs (et lutter contre l’amplification en écriture), mais c’est le disque qui fait tout le boulot. Donc ça reste incompréhensible pour moi le coup de ce disque d’archivage qui ne marche pas de base avec un ordi.
#8
En fait, ça s’utilise avec du matos entreprise spécifique donc on s’en fout si c’est pratique ou pas au final… C’est pas fait pour être mis dans un PC, quoi…
#9
Je suis étonné qu’ils ne soient pas passés à des enceintes sous vide pour les disques durs… j’aimerais bien savoir la raison (je doute que le différentiel de pression ni l’étanchéité de soient de vrais problèmes)
#10
Il faut un gaz je crois, parce que les têtes “flottent” au-dessus du disque à très faible distance.
En effet, ça serait facile sous vide (ou pression réduite), les disques durs étant déjà lourds et en métal (et pouvant s’alourdir si besoin).
#11
Mais elles survolent la surface grâce à l’air ?
#12
La raison est que la tête de lecture doit survoler littéralement le plateau pour ne pas s’y crasher/le rayer/etc., comme sur un coussin. Il faut donc nécessairement un gaz pour ce faire.
#13
Visiblement, j’ai ma réponse…
C’est fou, je pensais vraiment qu’ils utilisaient un autre moyen. Il doit y avoir un sacré vortex quand les disques tournent à fond
#14
Pourquoi la course à la capacité continue-t-elle avec des disques durs “classiques”, et non avec des SSD ? Pour le moment, les SSD sont encore plus chers, mais à terme et avec le volume, leurs tarifs devraient continuer de chuter. Les disques durs classiques n’ont pas vocation à disparaitre d’ici 5 ou 10 ans ?
#15
C’est une toute autre époque ces disques durs, avant les nouvelles capacités remplaçaient les anciennes avec un prix équivalent ou presque, maintenant, c’est toujours de plus en plus cher et les prix deviennent vraiment exorbitants… Difficultés de fabrication ? Moins de ventes ? ?
Ils vont taper dans les 1000 boules ces 18 To.
Bon je reste avec des 4 To du coup
#16
Il y a encore un facteur 5 à 10 entre le prix au Go des SSD et des HDD. Donc pour ceux qui ont des très gros besoins de volumes, sans avoir besoin de performances extrêmes, le HDD reste, et de loin, la solution la plus intéressante.
En outre, les producteurs de mémoire flash seraient absolument incapables aujourd’hui de couvrir la demande de volume qui est assurée par les fabricants de disques durs. Donc si les gros consommateurs de To se tournaient vers les SSD, l’effet ne serait pas une baisse de prix sur les SSD, mais, au contraire, une hausse, à cause d’un marché devenant trop tendu.
#17
Depuis un moment les fabricants de disques durs peinent à augmenter les densités de stockage. Du coup, ils compensent en ajoutant des plateaux, ce qui est de plus en plus compliqué (chauffe, vibrations, fragilité…) et coûte forcément bien plus cher à fabriquer. Il y a quelques années, en 3.5”, la plupart des disques durs avaient 1 à 4 plateaux, et quelques très rares modèles en avaient 5. Aujourd’hui, pour les plus grosses capacités de disques, les constructeurs empilent jusqu’à 9 plateaux.
#18
Tu n’es pas seul
, je me souviens de mes premiers PC pour lesquels 256 ko de RAM était le standard 
#19
C’est sur mais quand ils vont vouloir augmenter encore plus la densité des dits plateaux en HAMR ou MAMR, je me demande bien ce que cela va donner…
#20
Argh j’ai eu un 286 avec un disque dur de ce type avec mon 1 mo de ram. Ce que je me sens vieux tout d’un coup…
#21
C’est une question de performances. En drive managed, le support de stockage est obligé de faire les réécritures, même si en pratique les données qu’il va réécrire vont ensuite être écrasées par l’hôte.
En host managed, on évite des réécritures inutiles.
Pour un SSD, c’est moins important, car les performances sont très élevées et car la taille des pages et même celle des blocs d’effacement sont relativement faibles (quelques Ko pour les pages, quelques centaines de Ko à quelques Mo pour les blocs d’effacement).
Pour un disque dur par contre, selon la façon dont le SMR est implémenté (le nombre de pistes successives qui se chevauchent entre deux pistes sans chevauchement), la taille “minimale” d’une écriture peut aller de quelques dizaines de Mo (une piste sur le bord extérieur d’un disque récent faisant de l’ordre de 1.5 à 2 Mo) à plusieurs Go. Dans le cas le plus extrême (probablement pas utilisé en pratique), où l’intégralité des pistes se chevauchent, ça peut même aller jusqu’à la capacité du disques. Donc les performances peuvent se retrouver fortement dégradées. Le host managed est même obligatoire dans le cas où la taille d’un bloc de pistes dépasse la taille du cache.
De plus, sur le SSD c’est plus simple techniquement, mais aussi moins risqué, car en pratique les réécritures se font par déplacement des données : on prend une bloc vierge dans le pool de blocs vierges disponibles, on y recopie les données (avec les modifications) et on efface l’ancien bloc pour le mettre dans le pool de blocs vierges. Si l’alimentation est interrompue pendant l’opération, on a toujours les données d’origine, on perd juste les modifications récentes (c’est l’ancien bloc qui reste référencé tant que l’écriture dans le nouveau bloc n’est pas intégralement terminée).
Sur un disque dur SMR, la réécriture se fait sur place, les données sont réécrites au même endroit (d’où le fait qu’on ne peut pas avoir un bloc de taille supérieure à la taille du cache). Et dès qu’on a commencé la réécriture d’un bloc, s’il y a une perte d’alimentation on a une perte de données, pas seulement sur les nouvelles données, mais aussi sur les anciennes.
#22
Est-ce que c’est encore possible d’ajouter des plateaux en plus ? Pour passer à 10 voir plus ?
#23
Ça va devenir compliqué je pense… Déjà 9 plateaux, c’est énorme, un HDD 3.5” fait environ 25mm d’épaisseur, donc en comptant la coque extérieure de chaque côté (sachant que sur les disques à l’hélium, il y a une double coque sur la face supérieure, une première coque classique, vissée et avec des ouvertures pour réguler la pression interne dans le boîtier, et une seconde coque plus fine soudée par dessus pour assurer l’étanchéité), il doit rester un espace de l’ordre d’une 20aine de mm dans lequel il faut empiler 10 bras (en supposant que les 9 plateaux sont double face) et 9 plateaux, ainsi qu’un peu d’espace entre les bras et les plateaux. Doit vraiment plus rester beaucoup de marge de manoeuvre, sachant qu’affiner les plateaux ou les bras n’est pas sans risque pour la fiabilité…
#24
Plus précisément c’est l’atmosphère qui sert de lubrifiant à tout le système (moteur compris).
Ce qui provoque les frottements ce sont les irrégularités de surface (même pour la pièce la mieux polis du monde, il existe de très nombreuse irrégularité au niveau moléculaire, ce sont ces irrégularités qui provoquent des frottements).
Il faut donc un lubrifiant. Un gaz en est un : il va combler ces irrégularité (comme le fait de l’eau ou une huile).
A ma connaissance on ne peut pas utiliser de mécanisme de contact sous vide (lubrifiant obligatoire).
Ce n’est d’ailleurs pas pour rien qu’une bonne partie des rovers lunaires / martiens sont étanche (et remplis de gaz).
#25
Juste pour info sur les disques d’archive en SMR c’est en fait déjà très répandu.
Seagate en vend énormément depuis 5 ans, je me rappelle bien des premiers Seagate “Archive” ST8000AS002, qui offraient un prix imbattable à l’époque (~180€ pour 8 To).
Aujourd’hui quasiment la moitié de la gamme Seagate est en “SMR” (écriture des pistes en “tuile”), et on a d’ailleurs du mal à savoir quels disques sont en SMR et lesquels ne le sont pas (Seagate n’est pas très transparent là dessus).
Si ça se trouve tu en as déjà un sans t’en rendre compte :)
Par exemple les disques 8 To pour Xbox sont en SMR, beaucoup de petits HDD externes 2,5” de 3 à 5 To sont en SMR (ST3000LM005 etc.)
Et avec ces disques, on est en “drive managed”, ils sont vu par l’OS comme des disques classiques.
Quand le disque est vide la vitesse d’écriture est normale (~100Mo/s au début du disque, 60 à la fin), les pistes sont simplement écrites les unes après les autres en chevauchement, entrecoupées par des zones d’espacement.
Par contre une fois que le disque est plein ou qu’on veut réécrire un bloc en plein milieu d’autres données, le disque est obligé “en interne” de lire toutes les pistes une par une et de tout réécrire “en tuile “entre deux zones d’espacement
Du coup on a des vitesses d’écriture qui tombent très bas si l’OS “s’amuse” à demander au disque de réécrire pleins de petits blocs (d’expérience on tombe vite à 10-20 Mo/sec).
Les disques “host managed” permettent d’ordonner les demandes d’écriture de manière à respecter l’empilage en tuile.
#26
Merci pour tes explications détaillées, c’était déjà relativement clair pour moi ; mais je persiste à penser que le firmware du disque ne peut que mieux connaître le fonctionnement interne du disque (son nombre de “pistes” réelles, la densité pour chaque piste en fonction de la distance au centre, etc.) que l’ordinateur hôte ; et donc que c’est étrange comme choix.
D’ailleurs un commentateur plus bas (aurejac, merci à lui) précise qu’il y a des disques SMR qui sont vus comme des disques normaux, gérant eux-mêmes l’écriture.
#27
Ça marche aussi dans l’autre sens : l’hôte ne peut que mieux connaître les données à conserver et celles qui peuvent être écrasées ;-) Et justement, c’est ça qui est important pour maintenir les performances avec un disques SMR : quand tu fais une écriture qui va déborder sur d’autres données, si tu sais que ces autres données n’ont pas besoin d’être conservées, ça simplifie vachement les choses…
Oui, et il précise aussi et surtout que ces disques là voient leurs performances s’écrouler quand on écrit à des endroits qui ont déjà été écrits. Parce que le disque dur doit réécrire ce qui est sur les pistes “écrasées”. Alors qu’en host managed, l’hôte peut par exemple savoir que les données n’ont en fait pas besoin d’être réécrites parce qu’elles vont de toute façon être écrasées plus tard, et ainsi on ne ruine pas les performances…
Pour faire une analogie avec un truc plus connu, c’est un peu comme le TRIM pour les SSD. Les anciens SSD géraient de façon totalement autonome (donc “drive managed”) leur pool de pages vierges, et il ne pouvait effacer des pages que quand elles n’étaient plus mappées sur aucune adresse LBA. Le résultat, c’est que ça réduisait la taille potentielle du pool de pages vierges (une fois que toutes les adresses LBA ont été écrites au moins une fois, le pool de pages vierges se limite à l’overprovisioning) et ça obligeait régulièrement le SSD à déplacer des données qui en fait n’avaient plus aucun intérêt, surtout quand le mapping LBA se faisait par bloc d’effacement et non par page : quand il fallait modifier une page du bloc, tout le bloc était recopié. Et avec le temps, ça dégradait les performances, tout en amplifiant l’usure. Avec le TRIM, on a une forme minimaliste de “host managed”, c’est l’hôte qui devient responsable de déterminer les données qui n’ont pas besoin d’être conservées et qui en informe le SSD. On bénéficie alors d’un pool de pages vierges plus grand (overprovisioning + tout l’espace non occupé par des données à conserver), on diminue les recopies de données (quand un bloc doit être recopié pour en modifier une page, le SSD ne recopie plus que les pages contenant des données à conserver, les autres pages sont laissées vierges, ce qui permet plus tard de les écrire sans avoir à de nouveau effacer et recopier le bloc…), on améliore la durée de vie…
#28
mais l’hôte ne SAIT pas comment le disque gère ses blocs, déjà ça passe par le filesystem (ok, géré par l’hôte, mais tu comprends).
oui j’ai compris la question des pistes qui se recouvrent, et des performances qui peuvent s’en ressentir. Quelque soit le “manager”, le résultat est le même. D’ailleurs pour de l’archivage, on écrit plutôt en séquentiel.
le TRIM est justement lié au fait que le disque est accédé par bloc et ignore ce que fait le filesystem à son niveau (qui est supérieur) : c’est le filesystem qui sait sur quels blocs envoyer le TRIM.
NB : c’est aussi ce qui fait la force de ZFS, qui gère directement les blocs au niveau RAID, du coup la reconstruction est plus rapide, d’autant que le filsystem est peu rempli.
#29
Le protocole utilisé dans le cas d’un host managed permet justement à l’hôte d’être informé sur ce genre de choses, via de nouvelles commandes dédiées à ça. Voir ici par exemple pour les commandes dans le protocole ATA : http://www.t13.org/Documents/UploadedDocuments/docs2015/di537r05-Zoned_Device_ATA_Command_Set_ZAC.pdf
Ainsi, l’hôte peut déterminer quelles sont les données affectées r quand il veut écrire à un endroit et il peut alors faire le nécessaire pour conserver ce qui doit l’être, et uniquement ce qui doit l’être. Et au passage, il peut réorganiser les données (regrouper en début de zone toutes les données à conserver de la zone, ce qui fait que par la suite de nouvelles données pourront être ajoutées en fin de zone sans avoir à faire de nouvelles opérations de recopie).
Non, justement, le résultat n’est pas le même. Si le “manager” a connaissance des données à conserver/à supprimer, contrairement au disque. Donc dans le pire des cas (toutes les données affectées par une écriture sont à conserver), on a la même pertes de performances, mais dans le meilleur des cas (que des données qui peuvent être écrasées), on n’a aucune perte de performance en host managed alors qu’on en a en drive managed.