Hitachi introduceert zakelijke mlc-ssd's

Hitachi heeft een reeks solid state drives voor zakelijke en server-toepassingen uitgebracht. De nieuwe Ultrastar-serie werkt echter niet met slc-geheugen, zoals gebruikelijk, maar met het goedkopere mlc-geheugen.

De Ultrastar SSD400M-serie van Hitachi Global Storage Technologies is verkrijgbaar in capaciteiten van 200 en 400GB. Hitachi maakt gebruik van Intels mlc-geheugenchips, die het bedrijf volgens een 25nm-procedé vervaardigt. De door Hitachi GST gebruikte chips zijn niet de doorsnee mlc-chips die Intel in zijn consumenten-solid state drives gebruikt, maar zogeheten emlc-chips, ofwel enterprise-grade multilevel cell-geheugen. Dat moet een langere levensduur hebben dan normaal mlc-geheugen; op de 400GB-drives zou 7,3PB aan data geschreven kunnen worden.

De solid state drives van Hitachi zijn uitgerust met een sas-600-interface en moeten maximale leessnelheden tot 495MB/s kunnen halen; schrijven gaat met maximaal 385MB/s. Het bijbehorende aantal iops bedraagt respectievelijk 56.000 en 24.000. De drives zouden, gezien het gebruik van mlc- in plaats van het duurdere slc-geheugen, als betaalbare ssd-optie in servers gebruikt kunnen worden. De inzetbaarheid voor thuisgebruik is beperkt; in laptops passen de 15mm hoge drives niet en voor de desktop zijn er waarschijnlijk goedkopere drives. Hitachi heeft de prijzen echter nog niet bekendgemaakt; de drives zijn pas vanaf september verkrijgbaar.

Reacties (28)

[TD-er]

Dat moet een langere levensduur hebben dan normaal mlc-geheugen; op de 400GB-drives zou 7,3PB aan data geschreven kunnen worden.

7.3PB is 7300 TB.
Oftewel 7300 / 0.4 = 18250x
oftewel 20'000x schrijven per sector.
Gewone consumenten-grade SSD's zitten op zo'n 5000x schrijven per sector.

Maar deze manier van notatie is natuurlijk een nog krommere berekening dan MTBF en zegt helemaal niets over de betrouwbaarheid van de schijf. (anders dan dat je eerst moet gaan rekenen om een idee te krijgen van het aantal keer schrijven)

Theoretisch kun je dus de schijf volschrijven (400 GB data) en dan 20'000x de laatste sector beschrijven en weer wissen en dan ben je door je schijf heen.
Met een sector-grootte (op flash-niveau, niet filesystem-niveau) zit je dan op een 10GB extra (512kB per sector)
Dus na 410Gb schrijven is 'ie stuk. Dat is net zo'n correcte benadering als stellen dat 'ie pas na 7.3 PB stuk is.

[P5ycho]

Theoretisch kun je dus de schijf volschrijven (400 GB data) en dan 20'000x de laatste sector beschrijven en weer wissen en dan ben je door je schijf heen.

Als je je een beetje verdiept in SSD-tech dan zul je zien dat er de laatste jaren prachtige flash controllers zijn ontwikkeld die uitgebreide wear levelling toepassen. Elk LBA adres kan gemapped worden aan een andere page bij iedere write, zo verdeel je de writes over alle sectoren. Die 7,3PB aan schrijfacties is dus ook zeker haalbaar.
Bijkomend voordeel is dat je de trage block erases kunt doen terwijl je de data ergens anders gemodificeerd wegschrijft, en daarmee de grootste bottleneck van flash geheugen kunt omzeilen.

Als je van emlc flash met 20000 writes per block uitgaat, dan is de write amplification factor trouwens 20000/18250 = ~1.1, wat zeer goed te noemen is.

[Reactie gewijzigd door P5ycho op 23 juli 2024 23:07]

[Femme]

Verder hebben alle ssd's een ruime hoeveelheid overcapaciteit, bij een consumenten-ssd doorgaans zeven procent en bij enterprise-ssd's 25 procent. Als deze ssd's van Hitachi ook 25 procent overcapaciteit hebben moet je dus eerst 25 procent van de flashcellen kapot schrijven voordat de beschrijfbaarheid van de adresseerbare opslagcapaciteit wordt aangetast.

[TD-er]

Ik ben nog geen controller tegengekomen die wear-levelling toepast op niet-vrije sectoren.
Tuurlijk zal de controller zoveel mogelijk schrijfacties proberen te combineren, dus dan is mijn eerder genoemde voorbeeld van 1 bit omschrijven van 0 naar 1 al niet praktisch haalbaar.
Maar je blijft houden dat de effectiviteit van wear-levelling af hangt van de hoeveelheid vrije sectoren en dat je niet de hele sector hoeft te veranderen om een hele sector opnieuw te moeten beschrijven. Dan is het totale schrijf-volume ineens een stuk kleiner in de meest beroerde situaties.
Tuurlijk kun je die 7.3 PB halen door elke sector maximaal 20'000x te beschrijven, maar het is absoluut geen praktische indicatie van de praktische levensduur van de schijf.


En hoe je die write-amplification berekent is mij een beetje een raadsel.
De write-amplification is (data die je naar de flash schrijft / data die de host schrijft) en dat heeft dus niets te maken met de verhouding van 20'000/18250, omdat die waarde niets zegt over het soort geheugen wat je gebruikt.
Als ik een enkele bit verander die weggeschreven moet worden kan die write-amplification een factor 512x1024x8 zijn bij sectoren van 512 kB groot.

Die write-amplification hangt ook nog eens heel erg veel af van het gebruikte OS (caching), het filesysteem (blocksize) en de toepassing (random access zoals voor databases of sequentieel gebruik).
Bij het schrijven van 1 grote file zal de write-amplification aardig de 1 benaderen, maar voor andere toepassingen zal die factor een stuk groter zijn.


Nog een andere eigenschap van MLC-flash:
De reden waarom MLC-geheugen minder schrijf-acties aan kan dan SLC-geheugen is omdat de waarde die opgeslagen en gelezen wordt eigenlijk analoog is. Het is geen '1' of '0' of '11' of '00', maar een analoge waarde die toevallig ergens tussen 2 waarden ligt.
Stel die analoge waarde loopt van 0.0 naar 1.0 en je hebt SLC-geheugen, dan kun je die grens leggen op 0.5
Alles erboven noemen we een '1' en alles eronder een '0'.
Bij MLC is dat bijvoorbeeld de grens op 0.75 , 0.5 en 0.25 en dan kun je 2 bits opslaan per cel.
Maar je hebt ook al flash-geheugen wat 3 of 4 bits kan opslaan per cel.
Dan is ook gelijk de reden duidelijk waarom MLC geheugen minder vaak beschreven kan worden. De hoogste waarden kun je na een aantal keer schrijven namelijk niet meer halen en dus verlies je het onderscheid tussen bijvoorbeeld '110' en '111'.
Die gemiddelde waarde van 20'000x schrijven per cel zal ook afhangen van wat je wegschrijft.
Als je altijd wisselt tussen '110' en '001' zal je sneller problemen krijgen dan wanneer je afwisselt tussen '011' en '100'. (afwisselen tussen naburige cellen, niet percee per cel) Maar goed, dat is een academische discussie, aangezien je bij dergelijke slijtage heel goed op de hoogte moet zijn van de architectuur van de cel en ook van de controle-mechanismen van de controller om dit soort 'worst-case' data tegen te gaan.


Kortom, het noemen van de hoeveelheid data die je zou kunnen schrijven is echt een onzin-parameter die totaal niet praktisch is.

[P5ycho]

Ik ben nog geen controller tegengekomen die wear-levelling toepast op niet-vrije sectoren.

Het is een kleine moeite om blocks die nog redelijk 'vers' zijn tov. andere blocks even te swappen met wat vermoeidere blocks. Dit hoef je niet agressief te doen en is een relatief kleine moeite firmware-wise. Aangezien alle controller firmware proprietary is kan ik dit niet verifieren natuurlijk, maar het lijkt me sterk als dit niet geimplementeerd is. Zou dit niet zo zijn, dan zouden gebruikers die hun schijf altijd 90% vol hebben met statische data en de laaatste 10% gebruiken als scratchpad in no-time een dode schijf hebben.

En hoe je die write-amplification berekent is mij een beetje een raadsel.
De write-amplification is (data die je naar de flash schrijft / data die de host schrijft) en dat heeft dus niets te maken met de verhouding van 20'000/18250, omdat die waarde niets zegt over het soort geheugen wat je gebruikt.

Heel simpel: Hitachi garandeert blijkbaar dat je voor elk block waar 20000 writes voor staan, je daadwerkelijk 18250 writes kunt doen. dat betekent dat de overgebleven 1750 writes verloren gaan aan write amplification. De SSD heeft dus een gemiddelde write amplification/overhead over zijn levensduur van 1.1x.

Als ik een enkele bit verander die weggeschreven moet worden kan die write-amplification een factor 512x1024x8 zijn bij sectoren van 512 kB groot.

Je schrijft bijna per 4KB (default cluster size in gros operating systems), en een flash page is over het algemeen ook 4KB. Je kunt prima per page schrijven, alleen het wissen is 'duur'. wordt case scenario is dan ook gewoon dat je per sector write van het OS een read-erase-write moet doen. That's it. De firmware is dan weer zo slim om meerdere writes op te sparen en deze samen in een eerder ge-erased block te schrijven, de LBA's te remappen en klaar. Het oude block wordt ondertussen als vrij gemarkeerd en gewist, klaar voor de volgende cached write.

Die write-amplification hangt ook nog eens heel erg veel af van het gebruikte OS (caching), het filesysteem (blocksize) en de toepassing (random access zoals voor databases of sequentieel gebruik).
Bij het schrijven van 1 grote file zal de write-amplification aardig de 1 benaderen, maar voor andere toepassingen zal die factor een stuk groter zijn.

Het is niet zo interessant om dit op OS-niveau te bekijken. de SSD controller werkt tussen fysieke storage en SATA protocol, en meer gaat hij er niet van weten. Dat een SSD bij flinke random writes wel eens sneller kan slijten dat zal altijd zo blijven, maar door genoeg overcapaciteit en/of agressieve block recombining (garbage collection) garandeert Hitachi dus een write amplification factor van 1.1, resulterend in een 7.3PB aan writes over zijn levensduur. No matter the load.

Nog een andere eigenschap van MLC-flash: [...]

We zitten, net als bij HDD's overigens, al lang op het punt dat de technologie zelf zo onbetrouwbaar is dat er flinke bakken ECC tegenaan gegooid moet worden om uberhaupt de data nog correct terug te lezen.
Wear levelling op bitniveau zou trouwens achterlijk duur zijn, omdat je dan elke te schrijven sector moet gaan vergelijken met het slijtpatroon van elke achtse van alle pages op de SSD. Dat is gekkenwerk.
Dan liever nog deduplication op sectorniveau implementeren trouwens.

Kortom, het noemen van de hoeveelheid data die je zou kunnen schrijven is echt een onzin-parameter die totaal niet praktisch is.

Nogmaals, Hitachi garandeert dmv overcapaciteit, wear levelling, write combining, caching etc en menig vernuftige algoritmes gewoon dat je die hoeveelheid data echt kunt schrijven. Het zijn enterprise-schijven, dus ze kunnen het ook gewoon niet maken om niet uit te gaan van worst-case scenario.

[Reactie gewijzigd door P5ycho op 23 juli 2024 23:07]

[ls470]

Toen ik een aantal jaren geleden (ik ben nogal vaag omdat't oude herinneringen zijn, nog van vooraleer de eerste performante (intel, indilinx) SSDs op de markt waren, dus eerder voor controllers van flashkaartjes of usbsticks dan voor SSD) algorithmes opzocht voor de Flash translation layer werd er al vermeld dat er 2 niveaus van wear leveling gebruikt worden: bij iedere schrijfoperatie wordt een andere vrije pagina genomen, en om de zoveel operaties worden ook niet-vrije blokken gebruikt zodat wear leveling effectief over de hele schijf gebeurt.

ivm je verhaal van MLC flash:
zelf heb ik geen 20nm e-mlc opgemeten, maar ik vind het raar dat je de hoogste waarden niet meer zou kunnen bereiken. Vanwege trap-up in het tunneloxide worden vooral de laagste waarden moeilijker te schrijven (wissen wordt eerder moeilijk dan programmeren), en als de hoogste waarden niet meer bereikt worden is het voldoende de programmeerspanning een beetje te verhogen (of dat die nu 20V of 22V moet zijn zal uiteindelijk niet ZO veel schelen op de grootte van de chip).
Veel belangrijker is dat de verschillende opgeslagen Vt waarden veel dichter bij elkaar liggen, zodat een kleinere verschuiving (lekstroom door SILC, of een verschuiving vanwege detrapping) zorgt dat de verkeerde waarde uitgelezen wordt.


Ten derde zul je vanuit het standpunt van de schijf nooit 1 enkele bit kunnen veranderen omdat een schijf niet per bit maar per sector geadresseerd wordt vanuit het OS (en het OS bovendien sectoren groepeert om het filesystem beheerbaar te maken) . Als jij in je toepassing 1 bit verandert zal windows nog altijd 512B (of 4kB) naar de schijf schrijven, en wordt het verschil tussen 1bit en 512B of 4kB gerekend als verlies in je filesystem, niet als verlies in de schijf...

[naarden 4ever]

Niet te hard van stapel lopen. Als je enige diepgaande informatie hebt m.b.t. SSD's, moet je toch ook weten dat TRIM na enige tijd van toepassing is. En bovendien wprdt de werkdruk over de cellen verdeeld (Zie Tips & Trucs van verleden maand), dus je zult misschien een aantal keer dezelfde geheugelcel te pakken hebben, maar dan gaat de controller toch echt wel op actie over om de werkdruk te verdelen.
En een beetje kwaliteit SLC's kunnen wel 100.000x beschreven worden. Dat staat gelijk tot 10 jaar non-stop gebruik.

[TD-er]

Als je enige diepgaande informatie hebt m.b.t. SSD's, moet je toch ook weten dat TRIM na enige tijd van toepassing is.

Het enige wat TRIM doet is vrijgegeven sectoren alvast wissen zodat bij een volgende schrijf-actie van die sector niet eerst de sector nog gewist moet worden voordat deze beschreven kan worden.
Bij NAND-geheugen kan je namelijk alleen maar een '1' in een '0' veranderen. Wanneer het andersom moet, moet je dus eerst de hele sector wissen (op '1' zetten) en dan de aangepaste data voor die hele sector opnieuw schrijven.

Bij een nieuwe SSD zijn alle sectoren al netjes gewist en zonder TRIM commando verliest je SSD dus snelheid (bij het schrijven) na 1x alle sectoren te hebben beschreven. Met het TRIM-commando behoud je die snelheid.

Het TRIM-commando heeft dus niets te maken met het wear-levelling algoritme.

En bovendien wprdt de werkdruk over de cellen verdeeld (Zie Tips & Trucs van verleden maand), dus je zult misschien een aantal keer dezelfde geheugelcel te pakken hebben, maar dan gaat de controller toch echt wel op actie over om de werkdruk te verdelen.

Dat klopt, maar dat neemt niet weg dat wanneer je 1 bit aanpast, dat je een hele sector opnieuw moet beschrijven.

En een beetje kwaliteit SLC's kunnen wel 100.000x beschreven worden. Dat staat gelijk tot 10 jaar non-stop gebruik.

Enterprise SLC's hebben inderdaad een opgegeven write-count van 100'000x, maar hier hebben we het over MLC flash. Welliswaar Enterprise-level, maar dat heeft dus maar een opgegeven write-count van 20'000x en consumer-grade heeft een write-count van 5'000x.
Hoe je op die 10 jaar non-stop komt weet ik niet, want het soort gebruik (en de vrije ruimte) heeft er wel degelijk mee te maken hoe vaak je op die write-count uit komt.

[P5ycho]

Het enige wat TRIM doet is vrijgegeven sectoren alvast wissen zodat bij een volgende schrijf-actie van die sector niet eerst de sector nog gewist moet worden voordat deze beschreven kan worden.

Het effect dat TRIM heeft is dat een 8tal LBA's (1 sector) geunlinkt kunnen worden van hun fysieke flash page, en deze zo als invalid gemarkeerd worden. Het resultaat is meer vrije (unlinked) pages, en dus meer keuze uit grotendeels vrije flash blocks voor de volgende lading page writes.
Worst case zal hier gemiddeld voor elke 10 nieuwe page writes er 1 page verplaatst en herschreven moeten worden, zie write amplification.

Het TRIM-commando heeft dus niets te maken met het wear-levelling algoritme.

Maar is wel zijn beste vriend

[Verwijderd]

Dan is ie niet stuk maar ben je beetje data kwijt en een flashchip minder(paar gieg?)

[TheekAzzaBreek]

Volgens mij ben je dan slechts een page kwijt, niet een hele chip.

[TD-er]

"Beetje data kwijt" die niet recovered kan worden is IMHO stuk.
Het zal je filesysteem maar zijn wat ineens niet meer bestaat.

Wat ik berekend heb is de kortste mogelijkheid om een non-recoverable error te krijgen en dus dat je ook werkelijk data kwijt bent.

Zolang je ruimte over houd voor de controller om dit soort dingen te voorkomen zal je dit niet zo snel krijgen, maar zodra je data kwijt raakt is je drive niet betrouwbaar en zou ik er geen data meer op willen zetten.

[Bazz0847]

De 7.3PB is de absolute maximale hoeveelheid data die de schijf ooit kan wegschrijven terwijl jouw benadering eerder richting het minimum gaat. De definitie is in mijn ogen wel degelijk in orde

[TD-er]

Wat zegt dat nou dat je 7300 TB aan data zou kunnen wegschrijven. Zeg dan gewoon dat een sector zo'n 20'000x beschreven kan worden. Dat zegt tenminste iets, zo'n idiote bovengrens zegt helemaal niets. Zelfs nog minder dan MTBF omdat deze waarde afhankelijk is van de capaciteit en dus niet eens te vergelijken is met een andere drive met andere grootte.

[ls470]

Je zou dat kunnen proberen, maar alle moderne cotrollers zorgen er voor dat de slijtage gelijkmatig over het volledige geheugen gespreid wordt (en verplaatsen zonodig gegevens die niet herschreven worden om hier voor te zorgen).
Die spreiding zorgt voor enkele extra schrijfoperaties naar het geheugen maar voor zulke schijven zul je wel kunnen veronderstellen dat dat mee in de berekening opgenomen is, en dat je redelijk op die 7.3PB (of 3.7PB in het geval van random write,als ik de datasheet juist lees) zult kunnen vertrouwen.

[TD-er]

Bij SSD's kun je 1 bit veranderen van 0 naar 1 en dan moet de hele sector opnieuw worden geschreven.
Dus dan nog kun je die 7.3 PB met een factor 512*1024*8 verkleinen en dan heb je alsnog alle sectoren 20'000x opnieuw beschreven.
Dan zit je dus op 1.75 GB en dan is 'ie ook stuk, zelfs al is je wear-levelling algoritme optimaal.

Mijn hele punt is dat het gewoon een compleet idiote manier is om de levensduur van een SSD te beschrijven.

[P5ycho]

Dat is het dus niet als je je even verdiept in de technologie, zie mijn reactie hieronder.
Die 7,3PB aan writes kan gewoon waargemaakt worden

[_Thanatos_]

Als je één bit verandert, komt dit in de schrijfcache (van de SSD, niet die van het OS). Ik verwacht dat een moderne controller pas gaat schrijven zodra er genoeg schrijfbare gegevens zijn.

[pietermx]

Aan de foto te zien zit het met de stabiliteit van de voeding (lees: voltage) in ieder geval goed, of ziet mijn oog daar geen dikke rij condensatoren?

[Verwijderd]

Die 'condensatoren' zitten daar om er voor te zorgen dat de spanning op de chip stabiel blijft tijdens het schrijf/lees process. Dit omdat de chip verschillende vermogen af neemt tijdens. Het is dus een sort buffer voor de chip.

Tevens zorgt deze condensator ervoor dat de schakel frequenties niet geheel weer terug vloeien naar het bord dat eventueel invloed kan hebben op andere condensatoren.

Het type condensator is Keramische zodat deze snel kan reageren (dit in tegen stelling tot een Elco) op wisselende vermogen.

Overigens, deze condensatoren hebben niet direct iets met de voeding bron zelf te maken.

[Bazz0847]

Even rekenen leert dat iedere cell 18.250 writecycles kan maken. De Deskstar 7K1000 serie (bijvoorbeeld) kan dat 50.000 keer. Dat verschil is noemenswaardig, maar het komt al heel aardig in de buurt! Mooi schijfje :-)

[Verwijderd]

ik dacht dat Hitachi zijn volledige HDD productie had overgezet naar samsung?

[Reactie gewijzigd door Verwijderd op 23 juli 2024 23:07]

[Femme]

Hitachi Global Storage Technologies is overgenomen door Western Digital. Blijkbaar opereert HGST nog steeds onafhankelijk van Western Digital.

[ZeRoC00L]

Maar dit is ook geen Hard Disk hé

[TheDeeGee]

En Samsung HDDs is overgenomen door Seagate (Helaas)

[mxcreep]

Vind je ?? Ik heb in SAN omgevingen goede ervaringen met Seagate...

[Verwijderd]

Wat een monsters dit, maar zoals in het artikel al wordt aangegeven zullen deze waarschijnlijk niet voor de particulieren op de markt komen. Wel jammer, beetje extra concurrentie om de prijzen omlaag te drukken is natuurlijk altijd welkom

[mxcreep]

Is toch ook extra concurrentie, alleen niet op gebied van consumer ssd's...