Disques durs SMR : Toshiba clarifie à son tour sa position

Coucou Seagate !
Disques durs SMR : Toshiba clarifie à son tour sa position

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.

Ce contenu est en accès libre

Il a été produit grâce à nos abonnés, l'abonnement finance le travail de notre équipe de journalistes.

ou choisissez l'une de nos offres d'abonnement :

23 commentaires
Avatar de white_tentacle Abonné
Avatar de white_tentaclewhite_tentacle- 29/04/20 à 07:01:18

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.

Avatar de fry Abonné
Avatar de fryfry- 29/04/20 à 07:27:37

(quote:46497:white_tentacle) 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.

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

Avatar de white_tentacle Abonné
Avatar de white_tentaclewhite_tentacle- 29/04/20 à 07:53:17

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…

Avatar de David_L Équipe
Avatar de David_LDavid_L- 29/04/20 à 07:58:29

(quote:46503:white_tentacle) ...

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é" ;)

Avatar de white_tentacle Abonné
Avatar de white_tentaclewhite_tentacle- 29/04/20 à 08:03:36

(quote:46504:David_L) 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é" ;)

C’est pas faux :).

Avatar de fry Abonné
Avatar de fryfry- 29/04/20 à 08:44:12

(quote:46503:white_tentacle) 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-8tbLe 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…

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)

Avatar de alex.d. Abonné
Avatar de alex.d.alex.d.- 29/04/20 à 09:18:34

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 ?

Avatar de fry Abonné
Avatar de fryfry- 29/04/20 à 09:47:47

(quote:46511:alex.d.) 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 ?

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 ...

Avatar de white_tentacle Abonné
Avatar de white_tentaclewhite_tentacle- 29/04/20 à 15:40:16

(quote:46513:fry) 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 ...

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.

Avatar de hwti Abonné
Avatar de hwtihwti- 29/04/20 à 17:00:07

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.

Il n'est plus possible de commenter cette actualité.
Page 1 / 3

Votre commentaire

Avatar de lecteur anonyme
Avatar de lecteur anonyme

2000 - 2020 INpact MediaGroup - SARL de presse, membre du SPIIL. N° de CPPAP 0321 Z 92244.

Marque déposée. Tous droits réservés. Mentions légales et contact