Ces derniers mois, une cryptomonnaie exploitant le stockage pour son activité a explosé : Chia Network. De quoi créer une pénurie au niveau mondial et inquiéter les hébergeurs. De son côté Sabrent a décidé d'accompagner la nouvelle avec des SSD à l'endurance record.
Il y a quelques jours, OVHcloud et Scaleway annonçaient prendre des mesures contre les clients exploitant leur infrastructure pour le « plotting » lié à Chia Network, une blockchain reposant sur le Proof of Space and Time (PoST).
De manière plus concrète, il s'agit d'une étape où les utilisateurs doivent effectuer de longues et multiples écritures, de préférences sur SSD pour aller vite. Les données générées doivent ensuite être stockées et mises à disposition du réseau. On parle alors de « farming ». Une activité rémunérée en cryptomonnaie (chia), que certains espèrent lucrative.
Problème, du fait de la grosse activité en écriture, les SSD TLC/QLC grand public voient leur durée de vie réduire très rapidement. Les développeurs conseillent de plutôt utiliser des modèles pour serveurs, disposant d'une meilleure endurance, ou des disques durs, plus longs mais plus durables. Sabrent a eu une autre idée.
PlottRipper : l'endurance avant tout
La société indique qu'elle profitera du Computex pour dévoiler ses PlotRipper. Il s'agit d'une gamme de SSD spécialement prévue pour le plotting Chia Network, via la technologie LifeXtention. Cette dernière n'est pas détaillée, mais promet d'atteindre une endurance jusqu'à 18x supérieure à des SSD classiques. Les débits ne sont pas évoqués.
Ainsi, plutôt que 3 000 To écrits (TBW) pour un SSD TLC classique de 2 To, Sabrent promet 10 000 TBW pour son modèle classique et 27 000 ou 54 000 TBW pour ses PlottRiper Pro de 1 To et 2 To. Il n'est pas précisé si ceux-ci utiliseront de la Flash Nand SLC ou MLC pour améliorer leur endurance... ce qui aurait un effet direct sur les prix.
La société promet néanmoins des modèles parmi les plus rentables sur marché. Cela restera à démontrer.
Commentaires (15)
#1
Déjà que j’ai pas encore de CG, commencez pas à scalper les SSD
#2
J’ai vraiment du mal avec le fait que les DD puissent être plus durables.
Je pense surtout que caund on plotte, on devrait mettre un max de cache RAM - même pour l’écriture sur un SSD. Hors le cache disque en écriture est désactivé la plupart du temps, et le cache en lecture je ne suis même pas sûr que Windows en mette un sur les SSD par exemple.
Bref, un cache RAM en écriture devrait limiter la casse déjà.
#3
Il faut vraiment que les gars des cryptos arrêtent les conneries… ils se comportent comme des sauterelles avec les ressources techniques.
Y’a une autre crypto qui s’est lancée récemment et qui mise sur la saturation de la bande passante ! C’est complètement débile.
#4
Sous Linux (et pas seulement, Windows aussi même si ça a l’air moins bien géré historiquement), la RAM disponible sert de cache en écriture, et on peut régler le comportement (pourcentage de la mémoire utilisé pour la rétention, durée de rétention, pourcentage à atteindre pour commencer à écrire, etc).
Mais vu qu’ici il s’agit d’écrire de grandes quantités de données sur disque (on parle de 100 Go et nettement plus), il faudrait de grosses quantités de RAM, donc à voir côté budget et même avant cela pour la simple faisabilité technique (taille max d’une barrette de RAM et nombre d’emplacements sur la carte mère).
#5
Dépasser 2To de RAM est déjà possible sur des serveurs, Intel ou AMD. (Mais ca pique, la segmentation commerciale imposant de prendre les gros CPUs…)
Une solution moins chère serait de créer un RAM disk sur PCIExpress: un FPGA et c’est parti !
A l’image de ce qui se faisait il y a quelques années:
https://www.newegg.com/gigabyte-gc-ramdisk-others/p/N82E16815168001
#6
Effectivement, le cache en écriture est actif même sous Windows 10!
Mais il est vachement limité: chez moi il ne monte pas en cas d’écritures aléatoires: on voit qu’il monte puis il s’arrête et là ça ralenti. En plus, dans les compteurs, le nombre d’écriture physique = nombre d’écritures logiques.
Il faudrait un cache un peu moins stupide, qui aggrège les écritures ensemble, les réorganise.
Un peu comme les cartes contrôleurs RAID haut de gamme, qui réarrangent le cache pour ne pas écrire deux fois au même endroit, écrire tout en même temps, se caler sur les tailles d’échange des pistes pour déplacer au minimum les têtes au lieu de réécrire plusieurs fois les mêmes endroits parce que 3 octets on changé, le tout sauvegardé par pile en cas de coupure de courant…
Bref, un carte comme celle qu’on avait sur les alpha :) (ou dans les SAN j’imagine, mais là c’est moins précis dans la doc)
#7
#8
Oui et même avant la version 10.
Je ne sais pas dans quelle mesure ce cache est réglable dans son fonctionnement, mais pas beaucoup il me semble. Il faut dire que Windows est à la base un OS “desktop” et pas fait pour gérer des applications de type serveur.
C’est ce que font depuis quasiment le début certains I/O schedulers (ordonnanceurs d’E/S) de Linux, d’ailleurs tu peux choisir celui que tu utilises, au boot je crois, et il y a régulièrement des tests comparatifs. Avec les SSD qui ont pris une place importante, les ordonnanceurs orientés disques magnétiques, qui cherchaient à optimiser en fonction de la géométrie des disques, sont délaissés au profit d’ordonnanceurs qui ne font rien (pas besoin avec un SSD et ses temps d’accès quasi nuls).
C’est ce que tentent de faire au mieux les ordonnanceurs dont je parle juste avant :-) .
#9
Le souci c’est le prix de la RAM quand même.
Et effectivement certains serveurs peuvent monter haut, mais on n’est plus du tout dans le grand public ni même marché geek haut de gamme. C’est ça que je rappelais aussi.
DDR2 et 150 MB/s, c’est vieux :-) .
Et je ne suis pas sûr que ça se fasse encore ou soit intéressant, vu les performances actuelles de SSD, dont avec le NVME et PCI-Express.
#10
Le probleme est surtout sur la durée de vie de ces SSDs. Un RAM disk est parfait pour ce type d’utilisation, avant le stockage “froid” sur un HDD.
On n’a pas le tarif de ces SSDs, mais avoir une (ou plusieurs) carte d’extension pour de la RAM fait sens, non ?
Cependant, rien ne me fera investir dans ce type de bouzin si c’est lié à de la crypto monnaie ….
#11
Windows 2000, option “partage de fichier”, petite case à cocher “optimiser”: 256Mo réservés pour l’OS et les applis, tout le reste pour le cache :)
Il fallait savoir où décocher cette fichue option pour récupérer sa RAM :)
Sauf que si on ordonnance les écritures, on évite d’écrire dix fois les mêmes cellules (il me semble qu’on ne peut pas écrire moins de 128Ko sur un SSD, mais nos OS sont en blocs de 4k.
Les cartes contrôleurs je ne sais pas, mais les SAN, c’est souvent du I5 avec un Linux bien paramétré par IBM - donc oui, j’imagine qu’en chinant, on doit pouvoir trouver tout cela sous Linux.
Encore faut-il comprendre les phénomènes physiques qui sont induits par des lectures/écritures et les solutions qui existent déjà depuis des années pour les mettre en oeuvre …
#12
Oui mais ça reste un cache sur lequel on n’a aucun contrôle particulier, contrairement à Linux (et Unix et les BSD sauf erreur de ma part).
Il faudrait faire une petite simulation mais de toutes façons à partir du moment où les écritures ne sont pas linéaires, effectivement les SSD écrivent à coup de ~128 k, et je ne pense pas que les ordonnanceurs qui peuvent regrouper des écritures voisines servent à quelque chose (pas aux performances en tous cas, ce qui est déjà un signe).
Effectivement les baies SAN un peu évoluées (IBM ou autre, EMC étant une des marques les plus connues) bénéficient d’un travail sur le sujet. J’ai pu constater vers 2014 en production qu’une de ces baies EMC un peu onéreuses, équipées de plein de disques magnétiques, tenait une belle charge en terme d’accès concurrents.
#13
Deux cas le font:
Les baies de disques à instantanés, comme les Dell SC, fonctionnent comme ça. Ca garanti des performances de fou, mais elle a un processde réallocation qui ressemble à de la défragmentation, mais entre plusieurs type de SSD (sinon on les flingue trèèèès vite), voir des HDDs (stockage moins cher avec cache SSD)
#14
Joli ce “dès l’or”
Oui on peut supposer que le SSD fait son maximum pour éviter d’écrire trop tôt, en utilisant un peu de RAM ; cela dit je ne suis pas sûr que beaucoup de modèles sont concernés, car il faut que le SSD intègre un condensateur assez important pour garantir l’écriture en cas de coupure de courant (pas forcément un gros condo mais il faut aussi que le firmware gère ça). Après, ça ne sert à rien au SSD d’avoir beaucoup de RAM, il suffit d’en avoir assez pour quelques blocs de 128 k ; dont pour les raisons que tu as mentionnées de fonctionnement de filesystem.
Ben vu qu’on écrit les données de toutes façons (que ce soit en place ou sur un nouveau bloc alloué, effectivement ce 2e cas avec les FS journalisés), on use tout autant le SSD me semble.
#15
Chui fatigué, désolé ^^
Et non tu ne l’utilise pas autant. Si tu prends un fichier de 5mo dans lequel tu écris quelques kilos, ce serait le bloc complet de 128k qui serait lu, modifié, écrit. Avec la journalisation, tu vas juste dire “mon fichier va de là à là, puis passe ici, puis repasse par là”. Le système de fichiers le gère très bien et ça ne pose aucun souci sur un SSD ^^ (contrairement aux disques durs qui n’aiment pas cette fragmentation).
Si tu modifies plusieurs fichiers pour moins de 128K, tu n’useras qu’un seul bloc dans le second cas, contre plusieurs pour le premier cas.