smanu a dit:

Difficultés de fabrication ? Moins de ventes ? ? Ils vont taper dans les 1000 boules ces 18 To.

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.

OlivierJ a dit:

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.

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.

xillibit a dit:

Est-ce que c’est encore possible d’ajouter des plateaux en plus ? Pour passer à 10 voir plus ?

Ç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é…

OlivierJ a dit:

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.

Ç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…

OlivierJ a dit:

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.

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…

OlivierJ a dit:

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

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

OlivierJ a dit:

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

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.