Disques durs SMR : Toshiba clarifie à son tour sa position
Coucou Seagate !
Le 29 avril 2020 à 06h40
2 min
Hardware
Hardware
Et de trois ! Après la découverte d'une utilisation parfois trop large du SMR par certains constructeurs, sans forcément le dire à leurs clients, tous finissent par livrer des détails à ce sujet. Un regain de transparence dont on regrette qu'il soit si tardif, et dont on espère qu'il perdurera.
Après Western Digital et Seagate, Toshiba entre dans la danse du « SMR Gate ». Dans un communiqué, l'entreprise rappelle l'intérêt de cette technologie pour ce qui est de la hausse de la capacité des HDD, tout en reconnaissant qu'elle peut avoir un impact sur les débits en écriture, notamment sur les accès aléatoires.
Et donc que de tels disques ne sont pas adaptés à tous les usages, la technologie utilisée devant être adaptée aux besoins et au marché visé. Comme Seagate et contrairement à Western Digital, ses modèles N300 visant les NAS n'utilisent donc pas la technologie SMR.
C'est par contre le cas d'autres références. Les P300, DT02(V) de 4 et 6 To pour le grand public ou optimisés pour les usages de type vidéo surveillance, mais aussi des L200 et MQ04 de 1 et 2 To, qui visent plutôt les PC portables et autres solutions de stockage externe.
Comme pour Western Digital, qui a finalement détaillé ses références concernées, on regrette que cette déclaration ne s'accompagne pas d'un engagement à être plus clair à l'avenir dans l'ensemble des fiches techniques et pour l'ensemble des produits sur lesquels utilisent ou non la technologie SMR (ou d'autres du même genre).
C'est néanmoins préférable à la position de Seagate qui, après avoir vanté son refus d'utiliser le SMR dans les HDD pour NAS, refuse de dire clairement quels modèles utilisent cette technologie au sein de ses gammes grand public. La société se retrouvant désormais isolée dans ce manque de transparence.
Commentaires (23)
Abonnez-vous pour prendre part au débat
Déjà abonné ? Se connecter
Cet article est en accès libre, mais il est le fruit du travail d'une rédaction qui ne travaille que pour ses lecteurs, sur un média sans pub et sans tracker. Soutenez le journalisme tech de qualité en vous abonnant.
Accédez en illimité aux articles
Profitez d’un média expert et unique
Intégrez la communauté et prenez part aux débats
Partagez des articles premium à vos contacts
Abonnez-vousLe 29/04/2020 à 07h01
Si je comprends bien, ça concerne les principalement (uniquement ?) des disques à 5400 rpm ? Du coup, c’est complètement cohérent, si t’achètes un disque à 5400 rpm, c’est pas pour de la perf.
Le 29/04/2020 à 07h27
mouih, je suis moyennement d’accord
pour un nas par exemple, entre un disque 5400 qui fournirai du 180 Mo/s, et un 7200 qui monterait à 220Mo/s, le 5400 me suffirait amplement, (surtout si le nas est en gigabit) mais faut toujours pas qu’il soit smr …
rallonger un micro poil les temps d’accès pour gagner en bruit, chaleur et consommation ne veut pas obligatoirement dire vouloir un truc qui supporte pas des accès aléatoires en écriture
Le 29/04/2020 à 07h53
J’ai l’impression qu’il y a beaucoup de fantasmes sur l’impact réel du SMR. J’ai cherché rapidement, j’ai rien pu trouver de chiffré (à part dans les « worst case use »). Cet article donne quand même pas mal de détails : https://www.storagereview.com/review/seagate-archive-hdd-review-8tb
Le plus gros impact à mon avis, c’est que le rebuild d’une grappe raid en cas de défaillance est très lent (et ce n’est pas négligeable, plus il est lent, plus la probabilité qu’un autre disque lâche pendant l’intervalle augmente). Après tout dépend effectivement des usages… Pour un nas personnel plutôt utilisé comme archive que comme dossier de travail, ça ne changera pas grand chose. Pour un dossier de travail partagé utilisé intensivement en écriture, c’est sûr, ça ne sera pas pareil…
Le 29/04/2020 à 07h58
Dans tous les cas, il peut y avoir un impact. Les constructeurs ont essayé de se cacher un temps derrière des arguments de ce type “non mais vous comprenez, ça ne concerne que tel ou tel cas, bla bla bla”. Mais in fine : le client ne sait pas ce qu’il achète et ce n’est pas acceptable.
Après si les constructeurs veulent justifier leur choix de SMR sur telle ou telle gamme, à eux de le faire et de convaincre leurs clients. Mais quand un HDD est 5400tpm plutôt que 7200 tpm, le constructeur le dit clairement et non “On adapte les gammes de vitesse selon le besoin du marché visé” ;)
Le 29/04/2020 à 08h03
C’est pas faux :).
Le 29/04/2020 à 08h44
pour ma part j’ai 2 disques smr (je le savais pas à l’achat), un 8to et un 4to, le 8 me servait de nas (nextcloud) et le 4 pour des tests
je suis à peu près sur que c’est une charge de travail trop importante, qui aurait provoqué une réécriture d’un gros bloc smr, qui aurait lui-même entraîné un timeout, qui a finalement poussé linux a déconnecter le disque de 4to sur lequel je faisais des tests qui impliquaient des écritures en permanence (pas forcément de grosses écritures, mais très souvent, donc j’imagine pas de temps “idle” suffisant pour que le disque se réorganise de lui-même)
le 4to s’est déconnecté 2 ou 3 fois, du coup j’ai décidé de migrer ces tests sur le 8to => le 8to s’est retrouvé déconnecté lui aussi en 24h, alors que j’avais eu un uptime de 60 ou 80jours sans pb
je suis en train de tout migrer vers des disques non-SMR, je verrai bien si mes soupçons se confirment ou pas (c’est peut-être le pi qui supporte pas le niveau d’I/O des test et j’aurai le même pb, mais remplir le nas (2.6to utilisés) d’une traite (ou presque) ou les rsync pour migrer vers le disque non-SMR n’ont pas provoqué de déconnexion)
Le 29/04/2020 à 09h18
Je ne suis pas sûr de comprendre : si le SMR est si pénalisant que ça pour les performances en accès aléatoire, on peut retrouver l’info par nous-mêmes avec un simple benchmark, non ?
Le 29/04/2020 à 09h47
bah on doit pouvoir créer un script qui va faire des accès selon un certain profil, mais tous les disques smr ne s’effondreront peut-être pas avec le même profil, j’ai lu que la partie “normale” (qui sert de cache) peut varier en gros de 10 à 100go, faut donc un script qui va saturer le disque et la partie “normale” jusqu’a 100 go
et peut-être que certains systèmes de fichiers peuvent atténuer le pb, par exemple, si j’ai bien compris, le btrfs ne remplace pas les données quand il y a une modification, il écrit la nouvelle version dans un emplacement libre puis “libère” l’espace occupé précédemment (ce qui le rend efficace pour les snapshots, c’est natif, ou pas loin), du coup avec un truc comme ça je sais pas si on se retrouve à faire beaucoup de réécriture qui font s’activer toute la gestion spécifique au smr …
Le 29/04/2020 à 15h40
Il fait du « COW », c’est à dire que copier une donnée est gratuit tant qu’elle n’est pas modifiée. C’est ça qui permet de faire des snapshots quasi instantanés, et sans bouffer de place. Je ne sais pas à quel point ça joue sur les perfs du SMR, si ça a un lien.
De mon côté, j’ai aussi un disque SMR (idem, découvert après l’achat), mais c’est un disque de stockage, donc ce n’est pas gênant en soi. Et il est effectivement en btrfs. Je n’ai pas trouvé que copier (quand j’ai migré) avait été particulièrement lent.
Le 29/04/2020 à 17h00
En espérant qu’ils donnent systématiquement l’information à l’avenir, et qu’on ne trouve pas SMR et CMR sous la même référence.
Le 29/04/2020 à 17h45
Je pense aussi, j’aime savoir ce que j’achète. Mais si le prix est correcte et la techno adapté à l’usage. Je n’ai rien contre le SMR. Mais je trouve puant qu’ils tentent de le cacher (ça me rappel WD et la vitesse de rotation de ces disque qu’il ne voulait pas communiquer il y a 10-15 ans, pffff!).
Pas sûr du tout sur ce point. Le SMR doit pouvoir être dramatique sur des accès aléatoires en écriture (comme rappelé dans l’article
)
Mais un rebuild (un full) il n’y a rien de plus linéaire, ça me semble tout à fait adapté au SMR. Mais sans connaître la taille des blocks SMR, il y a toujours un risque de tomber sur un mauvais alignement + un mauvais timing qui pourraient potentiellement démultiplier les écritures pour rien.
C’est comme le disques 4k (tous les disques de nos jours, il me semble), le disque présente au système des blocks de 512 octets. Mais en interne il gère des blocks de 4096 octets. Si ta partition et les blocks de ton FS sont mal alignés/dimensionnés, ils pourra y avoir une perte de perf importante. Même si j’imagine que les firmwares et les caches des disques doivent pouvoir atténuer cette perte.
Pour moi le SMR c’est pareil.
Les SDD qui font des écritures par blocks de plusieurs Kio, c’est aussi le même principe (si le bloc a déjà été utilisé, je crois).
D’où l’intérêt du TRIM (dire au disque les blocs qui ne sont plus utilisés par le FS), qui doit aussi avoir son intérêt sur un disque SMR. Et dans un autre article (ou ses commentaires ?), il était justement fait mention d’une fonction TRIM en plus sur les disques SMR de WD.
M’est avis qu’il y a intérêt à utiliser le TRIM sur un disque SMR, comme pour les SSD, ça lui évitera de récrire des données correspondant à des fichiers supprimés.
J’utilise le raid logiciel sous Linux (via mdadm), je me demande si le TRIM est supporté par mdadm ? On dirait que oui. Mais pas certain de comment ça se passe exactement ? Et avec une partition luks ?
Le 30/04/2020 à 06h10
C’est pourtant ce qu’ils ont constaté dans l’article que j’ai mis en lien. Mais en même temps, de mon côté, copier 1.5 To de données sur un disque SMR ne m’a pas semblé spécialement lent (il faudrait que je vérifie, à l’occasion).
Le TRIM a du sens dès le firmware du disque fait de la translation d’adresse. Si j’ai bien compris, ça peut être le cas de certains disques SMR qui optimisent le cas où il reste de la place (un peu comme les SSD QLC qui fonctionnent en SLC tant qu’ils ne sont pas pleins).
Normalement c’est supporté, mais il y a souvent une option spécifique à rajouter ([i]discard[/i]). Tu peux lancer fstrim -n -a pour vérifier s’il y a des blocs inutilisés non libérés au niveau fs, déjà (mais je n’ai jamais réussi à savoir à quel point ça « traversait » les couches lvm/luks si les options ne sont pas présentes, et donc si c’est réellement fait ou alors au contraire perdu).
Le 30/04/2020 à 08h35
Le problème c’est pas les perf’ de la techo SMR mais le mixage avec le CMR au sein d’une même référence.
Ce qui peu occasionner dans certains cas des désynchronisations des grappes RAID. Et ça c’est beaucoup plus chiant…
Le 30/04/2020 à 10h50
Je suis un peu deg d’avoir acheté un WD sur cette période alors… Le miens est plutôt bruillant. Peut être que j’aurai prendre un Toshiba pour mon NAS…
Le 30/04/2020 à 13h08
Comme quoi contrairement a ce que pense certaines personne les différences entre gamme de disque n’est pas juste un firmware.
Un petit tableau en fin d’articles aurait était pratique ;)
Le 01/05/2020 à 16h32
Bonjour à tous,
Je vois que Toshiba indique que sa gamme N300 n’est pas concerné par le SMR, bien.
Mais qu’en est-il pour la gamme X300 ?
J’en possède deux utilisé dans un NAS Netgear RNDU2000 (readyNAS Ultra Duo).
Merci d’avance à tout ceux qui aurait une réponse.
Le 01/05/2020 à 22h23
Ta réponse est dans le premiers lien de l’article.
Le 01/05/2020 à 23h44
@ben51
Merci pour ta réponse.
J’étais passée à coté de ce lien…
Donc il semble que les X300 ne soient pas concernés comme les N300.
Encore merci.
Le 03/05/2020 à 09h20
J’ai été “victime” de ce cas que j’ai remonté sur le site support de WD.
J’ai changé 2 x HDD WD Red 3 To par 2 x HDD WD 6 To dans une grappe SHR (RAID 5 Syno) de 4 xHDDs.
J’avais donc un mix de 2 SMR et de 2 CMR.
Il me faut souligner que j’avais trouvé curieux que le cache passe de 64 Mo pour les anciens 6 To à 256 Mo pour les nouveaux 6 To.
J’ai compris qu’il ya avait un problème après la première reconstruction où lors d’un index, j’avais le volume qui était occupé à 100% ce qui absolument pas normal.
J’ai ensuite fait des tests de performances et en effet il y avait bien un problème sur mon volume avec des latences importantes.
J’ai alors demandé un remplacement des 2 x HDDs de 6 To par 2 x HDD de 8 To toujours des WD Red.
Ce remplacement m’a coûté 140€ en+.
Le 04/05/2020 à 07h49
Merci pour ton retour d’expérience. Ça confirme ce que disait Fab’z, un gros problème c’est effectivement le mix. Ce serait intéressant de voir ce que donne un raid de disques smrs (en ce qui me concerne, je suis passé au raid btrfs, qui structurellement est moins sensible à ce genre de problèmes).
Le 04/05/2020 à 09h54
Je serai bien passé au Btrfs mais c’est pas aussi simple d’ailleurs. Tu peux faire des tests de performance (lecture/écriture) mais cela dépend aussi de l’occupation des HDDs et du type de RAID ).
Le 04/05/2020 à 16h47
Raid 0 ou Raid 1 uniquement en btrfs (le raid 5, c’est toujours en « pas recommandé »). Par contre, il sait faire du raid1 sur trois disques (avec 3*4To, t’as 6To utilisables). J’essaierai de faire un test de perfs, mais de toute façon, sur un 5400 tpm faut pas s’attendre à des miracles (pris pour du stockage, pas de la perf)
Le 05/05/2020 à 11h58
Je me suis fait avoir en achetant un disque Seagate 4To utilisant cette technologie pour mon pc de bureau. A l’époque je ne connaissais pas du tout cette technologie, pour moi un disque dur c’était un disque dur, point barre.
Je m’en servais pour y mettre mes documents et programmes qui ne tenaient pas sur mon SSD système. J’ai très vite déchanté.
Lors d’une grosse activité disque dur (copie de fichiers par exemple) je voyais le débit soudainement chuter, le disque gratter à mort et devenir inaccessible. J’avais pensé à un disque défectueux qui “surchauffait” ou pire au contrôleur de ma carte mère qui déconnait . Changement en SAV et rebelote avec le nouveau.
Je me retrouve avec un disque payé cher et devenu inutile. Je ne peux même pas installer un jeu dessus, ayant une très bonne connexion Internet le disque n’arrive pas à digérer et me fait planter Steam.