Japanse middleware voor ssd's belooft flinke snelheidswinsten bij schrijfacties

Japanse onderzoekers hebben met behulp van aanpassingen in de middleware voor het aansturen van ssd's naar eigen zeggen de schrijfsnelheden tot 300 procent kunnen verhogen. Ook zou de software het stroomverbruik en het aantal write/erase-cycli aanzienlijk kunnen verlagen.

Dat meldt de Japanse media-organisatie Nikkei. Onderzoekers aan de Chuo University hebben naar eigen zeggen een zogenaamde LBA-scrambler aan de ssd-aansturing toegevoegd. Dit softwareonderdeel communiceert met de flash translation layer van de ssd. Deze zet logische adressering van het gebruikte bestandssysteem om naar fysieke adressering.

Door de logische adressering bij schrijfopdrachten via de LBA-scrambler aan te passen moet er efficiënter data naar een ssd geschreven worden omdat er minder fragmentatie ontstaat. Daarbij wordt data weggeschreven in een gefragmenteerde page van een geheugenblok dat door het garbage collection-mechanisme van de ssd-firmware gewist zal worden. Hierdoor wordt het aantal benodigde write/erase-cycli verlaagd.

Volgens de onderzoekers zorgt het toepassen van LBA scrambler in simulaties al naar gelang de toepassing tot snelheidswinsten van 300 procent bij schrijfacties. Ook zou het energieverbruik tot 60 procent kunnen afnemen en het aantal write/erase-cycli met 55 procent worden teruggebracht. Dit laatste komt de levensduur van een solid state disk ten goede. De implementatie van de LBA scrambler-middleware zou ook op bestaande ssd's toegepast kunnen worden.

LBA scrambler

Lees meer

Reacties (38)

Verwijderd 23 mei 2014 16:50

Een LBA-scrambler; welja...

Dit soort 'agressieve' technologie is niet in het belang van gebruikers. Computertechniek werkt redelijk betrouwbaar als alle onderdelen als kleine afzonderlijke units precies doen waarvoor ze gemaakt zijn. Zo hebben we een werkende complexe machine gebouwd waarvan we eigenlijk alleen nog de individuele modules begrijpen. Het geheel is te complex geworden; en bij vage problemen weet je dan niet waar je moet zoeken.

Een LBA scrambler betekent dat er een extra laag met complexiteit wordt toegevoegd aan een toch al complex geheel. Het is sowieso een slecht idee; dergelijke functionaliteit dient met de host-laag versmelt te worden en niet als afzonderlijke laag toegevoegd te worden. Want wat gaat er nu gebeuren?

1. Een programma wil informatie wegschrijven, hiervoor gebruikt het de API.
2. De API interfaced met het filesystem, het filesystem kiest een LBA-locatie uit en schrijft daar naartoe.
3. De LBA scrambler verandert de I/O requests; in sommige gevallen zou het ook moet knippen en plakken wat het geheel nog complexer maakt.
4. De LBA scrambler geeft vervolgens de veranderde I/O requests door aan de SSD.

Wat hier natuurlijk fout gaat is dat laag drie helemaal niet hoort te bestaan. Als het efficiënter is om naar een andere LBA-locatie te schrijven, dan dient deze functionaliteit in laag twee ondergebracht te worden; bij het filesystem. Die heeft de meeste kennis en daar hoort dergelijke functionaliteit thuis. Door een los onderdeel aan de I/O-keten toe te voegen, heb je het geheel complexer gemaakt en complexiteit is de vijand van probleemloos functionerende techniek.

Ik ben hier dus geen voorstander van. Je kunt beter verbeteringen in het OS of filesystem doorvoeren dan gaan kliederen met third party functionaliteit, zoals RAPID en deze LBA scrambler. Denk bijvoorbeeld aan de compatibiliteit; je kunt dan je SSD alleen maar uitlezen op Windows PCs met die scrambler software/drivers geïnstalleerd. Dit is niet de juiste manier om storage te verbeteren. Bovendien kunnen SSDs snel genoeg schrijven en heb je meer snelheid nodig dan zet je er een paar in een striping RAID configuratie. Throughput is niet echt een issue meer.

johnkeates @Verwijderd • 23 mei 2014 17:39

De LBA scrambler komt niet in je OS, maar in de firmware van je SSD. Voor de host kant verandert er niks.

Op het moment heb je ook geen ruwe toegang tot je NAND chips, er verandert eigenlijk niks. De FS of block device software kiest een LBA, maar dat is nu al niet eens een 'echte' LBA, want die wordt door de FTL nu al gemapt en geremapt.

Stel dat je dit bijvoorbeeld embedded zou doen, met Linux waarbij je rechtstreeks NAND aanspreekt met bijvoorbeeld JFFS. Dan stop je LBA scrambling code in JFFS. Er is dan geen FTL, en geen middleware.

Op het moment zijn er al zat algoritmes die "iets" doen met je host I/O requests, en ook zijn er heel veel die optimalisaties buiten requests doorvoeren en via GC mechanismen zelfstandig op NAND-niveau data manipuleren. Ondanks dat alles krijgt de host alsnog dezelfde LBA locatie contents goed binnen.

Dit is natuurlijk niet SSD-specifiek, HDD's deden dit uiteraard (zoals je zelf ongetwijfeld weet) al langer. Het is niet voor niets dat je rare dubbele LBA's en missende LBA's krijgt als je SA dood is maar de ROM je schijf nog steeds laat starten. Dit geldt natuurlijk ook voor RAID controllers, die doen ook het nodige met je I/O requests, en dat is eigenlijk nog een stapje enger, want dat is middleware bovenop je middleware! En wat dacht je van PCIe SSD RAID kaartjes... Dat is driedubbel middleware-ception. Middleware voor PCIe naar block, block naar raid, raid naar ssd, ssd naar nand... joepie.

Uiteindelijk is dat natuurlijk allemaal een stuk minder erg dan het lijkt. Adressen remappen, verplaatsen, scrambelen, algoritmes die I/O requests manipuleren maar toch magischerwijs altijd de juiste data teruggeven, het gebeurt natuurlijk al jaren. Het is dan ook zo'n beetje de kern van de moderne computer.

Verwijderd @johnkeates • 23 mei 2014 18:27

De LBA scrambler komt niet in je OS, maar in de firmware van je SSD.

Dan heb ik het verkeerd begrepen. Echter, ik begrijp het nog steeds niet helemaal.

Want... waarom dan een losse LBA scrambler? De FTL is toch al het onderdeel dat logische LBA omzet naar fysieke NAND? Dan kun je daar toch de algoritmen veranderen om dit efficiënter te doen en minder fragmentie te creëren? Tenzij het inderdaad niets meer dan een proof-of-concept is zoals diederikhu hierboven stelt.

Nu al wordt de plek waar de host naar wilt schrijven, niet meer gevolgd. De SSD kan er voor kiezen om naar fysieke plek X te schrijven en bij eenzelfde write request iets later op precies dezelfde plek (LBA) kan de SSD besluiten om deze write elders te schrijven. Dat is de hele functie van de FTL. De SSD slaat niet meer op wat de host opdraagt, maar past zelf intelligentie toe. Dat heeft een historie; een overzicht voor de liefhebbers:

In het stenen tijdperk
Vroeger werd de leeskop van de hardeschijf direct aangestuurd. Sommigen kennen nog wel het C/S/H (Cylinder, Sector, Head) wat je in het BIOS moest instellen voor schijven onder de 4GB. Dit stamt af van het tijdperk waarbij de software direct de hardware aanstuurde. De software moest hierdoor weten hoe de hardware werkte.

Omdat softwarefabrikanten en hardwarefabrikanten niet dezelfde zijn, zie je dat de twee werelden op zichzelf zijn gaan groeien. Hardwarefabrikanten voeren tweaks uit om tekortkomingen in software te adresseren. Dat wil je eigenlijk voorkomen, een hardwareapparaat dient een zuivere functie te hebben en geen software-specifieke tweaks.

LBA: virtuele opslag
De volgende stap was om storage te virtualiseren. Om niet langer de software op te dragen met het probleem hoe data moet worden opgeslagen op de hardware, maar dat de hardware dit zelf afhandelt. Dit is LBA - Logical Block Addressing. Dit betekent dat een opslagapparaat virtueel gezien wordt als een reeks van sectoren die geteld worden vanaf LBA0 (de eerste sector) tot LBA<groot getal> (de laatste sector). Lineair dus. Dit betekent dat de software gewoon naar LBA345 kan schrijven, en het opslagapparaat zelf weet wat het moet doen. Het krijgt dus extra intelligentie en er bestaat een formele gestandaardiseerde relatie tussen software en opslagapparaat.

Bij hardeschijven zien we dat LBA direct gekoppeld wordt aan een fysieke locatie. De software weet dus niet exact waar op de platter de data wordt geschreven, enkel de LBA locatie. Maar elke LBA betekent wel precies dezelfde plek.

Extra complexiteit: LBA wordt gevirtualiseerd
En juist dat is weer veranderd sinds de komst van 2e generatie SSDs, met Write Remapping (sinds Intel X25-M). De reden hiervoor is dat Windows en andere operating systems optimalisaties hebben ingebouwd voor hardeschijven en dat random writes op een SSD naar een bestaande locatie heel traag zijn. Om de tekortkomingen van NAND flashgeheugen te verzachten, werd extra complexiteit gecreëerd met een Flash Translation Layer (FTL) die voortaan de locatie van de data gaat onthouden. LBA345 betekent niet meer automatisch, NAND plek X. Met de FTL betekent LBA345 alleen iets als deze in de mapping tables voorkomt. Zo niet, dan probeert het geeneens van de NAND te lezen en stuurt het gewoon nullen terug. De SSD onthoudt dus alleen wat de host denkt opgeslagen te hebben, en via TRIM kan de host ook aangeven dat bepaalde opgeslagen data vergeten mag worden; dereferenced met een deftig woord.

De toekomst.... gone awry
De verkeerde weg is om steeds meer complexiteit in de SSD te stoppen. Sandforce begon met compressie (dat kan nog) maar ook met de-duplicatie. Dat laatste betekent dat er naast de mapping tables voor de FTL, nog een extra tabel moet worden onthouden: de deduplication table. Als één van beide corruptie zou vertonen, kun je niet meer bij je data. Ook kun je veel firmware bugs en issues verwachten door al deze complexiteit. Dat hebben we natuurlijk gezien bij Sandforce; extreem veel uitval. Hedendaags valt het mee omdat de bugs er onderhand wel uit zijn. Maar dit is dus de verkeerde weg....

En Samsung die met zijn RAPID-software een superonveilige RAM write-back creëert. En de klanten vinden het allemaal prachtig. Maar dit is natuurlijk gekkigheid. Zo kan ik ook tegen 2GB/s schrijven naar een floppydisk, zij het heel kort.

Bovendien, als er al dit sooft functionaliteit zou bestaan, zou dit in het operating system moeten worden gebouwd. Zo kun je onder BSD met het geavanceerde ZFS filesystem ook writes gaan bufferen wat in de vele gigabytes kan lopen. Maar dan doen je het op de veilige en juiste manier.

De toekomst.... done right
De juiste weg is om complexiteit te verbannen, niet om zaken juist nog complexer te maken. Zo heeft het mijn voorkeur om 'pure' NAND aan te sturen met software. Mapping tables en al die meuk wordt dan ook softwarematig gedaan. Zowel in Linux als in *BSD zijn hier drivers voor. Het voordeel is dat je pure NAND chipjes kunt aansturen, en zo de hele SSD controller onderuit haalt. Het nadeel, is dat je niet zomaar cross-OS compatibility hebt; het andere OS ondersteunt misschien helemaal geen puur NAND (Windows) of stuurt deze NAND op een heel andere manier aan die niet compatible is (Linux/BSD).

De juiste weg is ook om een oplossing te verzinnen voor de veroorzaker van complexiteit: de beperking van NAND dat het alleen kan worden overschreven als de hele erase block gewist en opnieuw geprogrammeerd wordt. Dat is traag en dat is de reden dat complexiteit is toegevoegd om SSDs toch snel te maken. Als we afstappen van NAND en naar iets als Phase-Change Memory (PCM) gaan, dan heeft dat inherente voordelen. De FTL kan dan worden afgeschaft en opslagapparaten gaan dan vrijwel nooit meer stuk, net als DRAM geheugen en processoren.

Ook kun je tmpfs gebruiken. Dit is een automatische RAMdisk die van grootte verandert afhankelijk van hoeveel RAM er op dat moment vrij is. Onder Windows bestaat deze functionaliteit niet. Je hebt alleen third party RAM-disks die virtuele LBA storage aanbieden. Dat is niet erg sexy, en ook flink trager dan een native RAM filesystem. Tmpfs is dus een filesystem voor RAM-storage. Dat zou bijvoorbeeld iets zijn voor WinRAR, Photoshop (scratch disk) en meer van dit soort apps die tijdelijk data moeten schrijven. Waarom zou je dat naar je disk doen als het ook naar RAM kan? Je dondert de gegevens toch weer weg zodra je klaar bent.

Kortom, ik zie liever innovaties op softwareniveau in het Operating System, dan dat hardwarefabrikanten opslag steeds maar complexer maken en met alle gevolgen voor de betrouwbaarheid. Dat hebben we bij SSDs gezien; terwijl door het gebrek aan mechanische onderdelen SSDs juist alle potentie hebben om flink betrouwbaarder te zijn dan mechanische hardeschijven.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 14:50]

robvanwijk @Verwijderd • 23 mei 2014 19:30

LBA: virtuele opslag
(..)
Bij hardeschijven zien we dat LBA direct gekoppeld wordt aan een fysieke locatie. De software weet dus niet exact waar op de platter de data wordt geschreven, enkel de LBA locatie. Maar elke LBA betekent wel precies dezelfde plek.

Meestal, maar ook niet altijd. Eén van de nadelen van klassieke harde schijven is bad sectors. Dat wordt tegenwoordig opgelost door de LBA van de kapotte sector te remappen naar het einde van de schijf (waar een aantal sectoren normaal gesproken ongebruikt blijft, speciaal gereserveerd voor deze toepassing). Tuurlijk, dat dit gebeurt is een zeldzaamheid, maar de firmware moet het wel ondersteunen, bij elke request kijken of ie geremapped moet worden en alle complexiteit en risico op bugs is net zo groot als bij FTL (misschien zelfs groter, omdat zeldzame bugs lang onopgemerkt kunnen blijven??).

De toekomst.... gone awry
De verkeerde weg is om steeds meer complexiteit in de SSD te stoppen. Sandforce begon met compressie (dat kan nog) maar ook met de-duplicatie. Dat laatste betekent dat er naast de mapping tables voor de FTL, nog een extra tabel moet worden onthouden: de deduplication table. Als één van beide corruptie zou vertonen, kun je niet meer bij je data. Ook kun je veel firmware bugs en issues verwachten door al deze complexiteit. Dat hebben we natuurlijk gezien bij Sandforce; extreem veel uitval. Hedendaags valt het mee omdat de bugs er onderhand wel uit zijn. Maar dit is dus de verkeerde weg....

Ik vind het met die complexiteit nog wel meevallen, zeker als je het vergelijkt met de complexiteit van andere onderdelen. Kijk maar eens naar elke moderne CPU; als je niet blij wordt van FTL dan zul je out-of-order execution helemaal een gedrocht vinden... maar om de performance te halen die we vandaag de dag gewend zijn kunnen we niet zonder.

Bovendien, als er al dit sooft functionaliteit zou bestaan, zou dit in het operating system moeten worden gebouwd. Zo kun je onder BSD met het geavanceerde ZFS filesystem ook writes gaan bufferen wat in de vele gigabytes kan lopen. Maar dan doen je het op de veilige en juiste manier.

Waarom in het OS!? Dan krijg je straks weer incompatibiliteiten.

Dat het nu opgelost wordt in de schijf zelf geeft je een perfect punt voor separation of concerns: het OS (en de FS driver) denkt na over hoe de structuur logisch gezien in elkaar zit, de SSD (of welk ander kastje dan ook dat je aan een SATA connector hangt, dat protocol snapt en data op kan slaan) zorgt dat dat op een efficiënte manier gebeurt.
Want laten we nou eerlijk zijn, welke code heeft een betere kans om de eigenschappen van een device correct in te schatten: code in het OS (die dus voor elk OS opnieuw geschreven moet worden!) of code in dat device zelf? Bovendien, zodra er een nieuw kastje komt dat op weer een andere techniek gebaseerd is, dan zou je alle OS installaties moeten gaan updaten...

De juiste weg is ook om een oplossing te verzinnen voor de veroorzaker van complexiteit: de beperking van NAND dat het alleen kan worden overschreven als de hele erase block gewist en opnieuw geprogrammeerd wordt. Dat is traag en dat is de reden dat complexiteit is toegevoegd om SSDs toch snel te maken. Als we afstappen van NAND en naar iets als Phase-Change Memory (PCM) gaan, dan heeft dat inherente voordelen. De FTL kan dan worden afgeschaft en opslagapparaten gaan dan vrijwel nooit meer stuk, net als DRAM geheugen en processoren.

Ja, zo ken ik er nog wel meer: de huidige techniek heeft nadelen, dus laten we overstappen op iets anders. Goed idee, maar niet iets wat in korte tijd te realiseren is. Je wilt toch ook niet voorstellen om uiterst complexe zonnecellen te laten voor wat ze zijn; we kunnen prima bruinkool stoken, lekker simpele techniek en dan stappen we daarna over op echt schone kernfusie... over vijftig jaar ofzo.
Goed dat er aan fundamenteel nieuwe technieken word gewerkt, mooi dat we daar ooit naartoe over zullen kunnen stappen, maar laten we alsjeblieft de huidige technieken zo goed mogelijk gebruiken totdat die overstap ook echt gemaakt wordt!

Ook kun je tmpfs gebruiken. Dit is een automatische RAMdisk die van grootte verandert afhankelijk van hoeveel RAM er op dat moment vrij is. Onder Windows bestaat deze functionaliteit niet. Je hebt alleen third party RAM-disks die virtuele LBA storage aanbieden. Dat is niet erg sexy, en ook flink trager dan een native RAM filesystem. Tmpfs is dus een filesystem voor RAM-storage. Dat zou bijvoorbeeld iets zijn voor WinRAR, Photoshop (scratch disk) en meer van dit soort apps die tijdelijk data moeten schrijven. Waarom zou je dat naar je disk doen als het ook naar RAM kan? Je dondert de gegevens toch weer weg zodra je klaar bent.

Niet dat ik het met je oneens ben... maar dit heeft werkelijk niks te maken met het artikel...

Verwijderd @robvanwijk • 23 mei 2014 19:45

Eén van de nadelen van klassieke harde schijven is bad sectors. Dat wordt tegenwoordig opgelost door de LBA van de kapotte sector te remappen naar het einde van de schijf (waar een aantal sectoren normaal gesproken ongebruikt blijft, speciaal gereserveerd voor deze toepassing). Tuurlijk, dat dit gebeurt is een zeldzaamheid, maar de firmware moet het wel ondersteunen, bij elke request kijken of ie geremapped moet worden en alle complexiteit en risico op bugs is net zo groot als bij FTL (misschien zelfs groter, omdat zeldzame bugs lang onopgemerkt kunnen blijven??).

Het grote verschil is dat de hardeschijf 0 tot 1000 sectoren heeft die een afwijkende fysieke locatie hebben. Die tabel moet inderdaad geraadpleegd worden. Maar dat is heel veel minder werk en gevaar dan de FTL die in een SSD zit. Die moet alle storage opnemen in de mapping tables, anders kun je de informatie niet meer uitlezen vanaf de host. Als de mapping tables beschadigd zijn of inconsistent, heb je problemen met je data. Dat probleem geldt niet voor hardeschijven die enkel bad sectors moeten remappen. Dat geldt voor een paar sectoren terwijl de rest gewoon een statische LBA kent.

Ik vind het met die complexiteit nog wel meevallen, zeker als je het vergelijkt met de complexiteit van andere onderdelen. Kijk maar eens naar elke moderne CPU

Punt gemaakt. Maar ken je de TLB-bug nog van AMD, die te laat werd ontdekt? Verder hebben veel CPUs errata bugs, wat niet erg is als ze op tijd worden ontdekt. Maar door de gestegen complexiteit is het gevaar dat er in de toekomst meer bugs te laat worden ontdekt, en je dan eigenlijk met een onbetrouwbare processor zit.

Maar de processor is tegenwoordig een SoC. Dus ook allemaal modules die met elkaar samenwerken. En de complexe legacy x86-architectuur zal ooit wel opgevolgd worden. Misschien door ARM. We zullen zien.

Waarom in het OS!? Dan krijg je straks weer incompatibiliteiten.

Software kan worden verbeterd; hardware niet (firmware is ook software). De theorie is dat je hardware puur en simpel wilt houden, en alle benodigde complexiteit in software onderbrengt. Als ergens een bug in zit, kun je updaten.

Verder is het probleem met OS-compatibility er eigenlijk al. Denk aan onboard RAID met Windows-only drivers. Het leuke is nu dat de RAID configuratie op de schijven zelf wordt geschreven (de laatste sector). Dit opent de weg om Linux/BSD om die informatie te lezen en de eigen software RAID engine aan te zwengelen. En dat is hoe het nu werkt.

Dit is ook wat ik voorstel. De pure NAND device kan informatie hebben over hoe het is 'geformatteerd'. Het OS kijkt of het dit template ondersteunt en zwengelt zijn eigen engine aan. Zolang er volgens dezelfde spelregels wordt gewerkt, kan dat prima cross-OS compatible zijn.

Want laten we nou eerlijk zijn, welke code heeft een betere kans om de eigenschappen van een device correct in te schatten: code in het OS (die dus voor elk OS opnieuw geschreven moet worden!) of code in dat device zelf?

De host heeft de meeste informatie. Denk aan hardeschijven waarbij je vaakgebruikte bestanden aan het begin wilt hebben omdat die plek sneller is dan het einde van de schijf. De hardeschijf zelf kan dit niet weten. Met statische LBA kan de host informatie die het wilt versnellen aan het begin plaatsen. Dergelijke intelligentie kan het opslagapparaat zelf niet uitvoeren.

Maar ik begrijp wel je punt dat bepaalde dingen het opslagapparaat zelf beter zou kunnen. Zoals waar de informatie intern moet worden opgeslagen. Ik wil niet terug naar het 'stenen tijdperk' wat ik beschreven heb in mijn vorige reactie. Ik wil terug naar virtuele LBA. Een simpele gestandaardiseerde interface tussen host en opslagapparaat.

Niet dat ik het met je oneens ben... maar dit heeft werkelijk niks te maken met het artikel...

Nou indirect wel. De reden voor de LBA scrambler is om 300% sneller te kunnen schrijven. Voor applicaties waarbij dit nuttig zou kunnen zijn, is tmpfs vaak een veel beter alternatief. Denk aan photoshop waarbij je een snelle scratch disk wilt hebben, enzovoorts.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 14:50]

johnkeates @Verwijderd • 23 mei 2014 19:42

Ik ben het met je eens, maar het lijkt me extreem ongewenst om realtime I/O op een niet-realtime manier in software of firmware te implementeren.

Het hele ding met flash-controllers, FTL's enz. is dat taken voor I/O realtime uitgevoerd worden en niet threaded of met blocking calls en semephores opgelost wordt.

Het zou zijn zijn als er een uitgebreide instructie komt binnen ATA dat je direct-NAND access aan kan zetten. Probleem is dan echter wel dat je ergens accounting enz. moet gaan opslaan buiten je SSD om. Met embedded toepassingen heb je meestal een EEPROM of NVRAM waar je dit kan opslaan, maar op x86(-64) platformen nagenoeg nooit. Ik heb het in elk geval nog niet in het wild gezien, en zeker niet op consumenten en andere normale-mensen-hardware (hier een daar op custom industriële oplossingen).

Het hele probleem met deze technologie is niet dat het niet kan, maar dat het dominante OS er extreem slecht mee om zou gaan (windows) om dat het simpelweg van de grond af aan opgebouwd is om met ouderwetse BIOS, MBR en LBA implementaties te werken en behalve in de embedded versies nauwelijks ingebouwde ondersteuning heeft voor iets anders. UEFI en GPT zijn later ook gewoon 'toegevoegd' om dat het moest en met Windows 8 en Server 2012 pas echt ingeburgerd geraakt, en zelfs daar nog niet helemaal netjes geïmplementeerd. Als je dan ook nog directe NAND-toegang zou willen hebben of OS-level RAM disks heb je al helemaal een probleem met toegevoegde blackbox complexiteit en (uiteraard door wisselende hardware implementatie) verschillende niveaus vendor ondersteuning. Windows wordt als general-purpose systeem op de markt gepresenteerd terwijl het daar helemaal niet open en flexibel genoeg voor is.

Met BSD, Unix en Linux zie ik nog wel mogelijkheden om dit soort dingen tot een standaard te verheffen waarbij je NAND a la DIMM in een dochterbord in een PCIe slot kan pluggen, maar de kans dat dat soort dingen lekker gaan werken met Windows zie ik nog niet gebeuren. Zelfs Mac OS X zou daar een betere kans in maken, maar die heeft natuurlijk het voordeel dat de hardware en software vendor 1 bedrijf is en alles dus 'weet' en kan doen. (geen geheimen, NDA's en andere crap die technologie in de weg staat)

Uiteindelijk zal dit soort spul vooral bij hardware vendors en UEFI implementaties pas op gang kunnen komen, en de vraag is dan natuurlijk of fabrikanten daar brood in zien. Ik denk het niet, vooral niet om dat ze voornamelijk naar sales kijken die door Windows komen, en die sales gaan echt niet hoger komen als ze direct-NAND-access ondersteunen. Hell, de meeste hardware vendors die UEFI firmware leveren met hun hardware gebruiken een of andere brakke standaard demo implementatie waarbij ze soms zelf de "FOR TESTING PURPOSES ONLY" strings niet uit het POST scherm halen.

Het zou ideaal zijn als je een microfirmware hebt die een kernel naar RAM kan kopiëren, waarna de kernel weer een microcode of microfirmware naar een FTL/SSD controleer kan sturen die daarna precies zo werkt als het OS wil. Probleem is dan wel weer dat je opeens een extra attack vector hebt, je opeens een stuk minder OS-interoperabele hardwar hebt (als iets dergelijks gemaakt zou worden gaat elk OS uiteraard andere microcode/firmware gebruiken, andere accounting en zijn de EEPROMS/NVRAMS/SA's niet meer cross-platform te gebruiken, LAME!)...

Misschien dat het volgende het beste van twee werelden is: I/O command optimalisatie. Dat je in je OS de SA/Accounting data kan uitlezen (read-only) en aan de hand daar van je LBA en andere I/O instructies zo kan optimaliseren dat de FLT of SSD/storage controller in het algemeen er beter op kan inspelen. Dat is ook wat de LBA scrambler doet (om het even bot en kort door de bocht te zeggen). Als je je I/O commands/request zo kan selecteren dat je hetzelfde als die LBA scrambler doet maar dan in het host OS, dan heb je in principe dezelfde optimalisatie, maar dan zijn de block-level drivers en filesystem drivers op de hoogte van de interne formattering. Mocht je de schijf in een ander systeem prikken of een ander OS laten aanspreken die die optimalisatie niet doet, dan werkt alles gewoon zoals het nu werkt. Lijkt me ideaal!

VOODOO_WILLIE @Verwijderd • 24 mei 2014 01:32

Helemaal mee eens en ik zou het ook graag anders zien maar dan hebben we dus het volgende:

en opslagapparaten gaan dan vrijwel nooit meer stuk

Dit zou de fabrikanten juist een doorn in het oog zijn. Als er niks meer stuk gaat dan worden er ook lang niet zoveel schijven meer verkocht. Om dat te compenseren zou zo'n schijf gewoon tien keer zo duur moeten worden.

Philips bijvoorbeeld had dit licht (ha-ha-hah

) al snel gezien met zijn gloeilampen.
Een sluwe slimmerik aldaar bedacht namelijk dat ze meer lampen zouden verkopen als die dingen niet meer zo verdraaid lang mee zouden gaan. Heel sneaky hebben ze daar bij Philips de levensduur express enorm omlaag gebracht.

Maar ze kunnen wel lang meegaan:
http://www.centennialbulb.org/index.htm

Fabrikanten zorgen er gewoon voor dat hun producten net zodanig lang meegaan dat de klanten net niet gaan zeuren.

Ik ben nog lang geen opa maar ik kan me de tijd nog herinneren dat een tv, wasmachine, stereo-installatie of oven makkelijk 20 jaar meeging.
Nu mag je al blij zijn als die dingen de 5 jaar halen.

Wat je ook als voorbeeld neemt, het gaat negen van de tien keer kapot als net de garantieperiode verstreken is.

Het is, hoofzakelijk, het in stand houden (en langzaam aan verergeren) van de consumptiemaatschappij.

falcon1 @Verwijderd • 23 mei 2014 17:47

Reden te meer voor een pass-trough mode voor SSD's, dan kan er ten minste in de software lagen al rekening gehouden worden met de eigenschappen van de hardware.

De huidige SSD "simuleren" gewone roterende schijven. Het OS gebruikt drivers die gemaakt zijn "roterende schijven" en adverteert naar programma's ook gewoon "roterende schijven".

TRIM is een al lapmiddel die niet nodig is als alle software gewoon weet dat er FLASH opslag gebruikt wordt. Random LBA is gewoon weer een lapmiddel.

Ook kun je met de huidige SSD door "obsucure" firmware niet goed en standaard achterhalen of voorspellen wat de levensduur is. Ook weet je van te voren niet of drivers en firmware elkaar tegenwerken of juist helpen. Of fouten herstellen.

Die jongens die voor Linux de Flash memory drivers/File systemen schrijven, de MTD driver, UBIFS, BTRFS, etc. willen dit ook eigenlijk:
http://www.linux-mtd.infradead.org/faq/general.html
http://lwn.net/Articles/428584/

Heel kort, Als de software weet dat er flash opslag gebruik word dan kan daar rekening mee gehouden worden resultaat:
Betere performance
Beter levensduur
Beter foutopsoring
Herstel mogelijkheid bij crashes/software fouten

Het zelfde geld voor USB sticks,Multimedia geheugen etc. uiteraard

Er worden lapmiddelen gebruikt om maar geen extra software te schrijven. Dus in plaats van lapmiddellen te schrijven/onderzoeken kunnen ze beter de oorzaak aanpakken.

Edit:
Beter gelezen: dit is software voor in de firmware. En staat in direct contact met de FTL. Zelfde als een passthrough mode maar dan direct op de processor van de SSD.

Toch zie ik dit liever in de software dan in de firmware.

Firmware moet zo klein mogelijk blijven en zo min mogelijk de hardware afschermen. Hoe groter de firmware hoe groter de kans op fouten en beveiligingsgaten.

Firmware is eigenlijk de verste vorm van closed-source software.

[Reactie gewijzigd door falcon1 op 22 juli 2024 14:50]

johnkeates @falcon1 • 23 mei 2014 19:28

Het probleem is echter dat een SSD firmware realtime I/O moet verzorgen, iets wat een time-sharing OS niet kan... zelfs met RTOS firmware op SSD's heb je nog dat programma's iowait en blocking status krijgen om dat ze op storage moeten wachten.

Er zijn ook genoeg opties om NAND flash direct aan te spreken (zie mijn post een stukje hoger, JFFS voorbeeld), maar dat levert altijd wel andere voorwaarden en eisen op die voor dagelijks gebruik niet goed genoeg zijn.

Wat de LBA Scrambler doet is de FTL 'met rust' laten, maar de LBA->NAND mapping optimaliseren door te zorgen dat GC-targets met gaten gebruikt worden voor gefragmenteerde pages in die gaten te stoppen. Dat zorgt er voor dat de GC geen write-cycles verspilt, en gezien de seek time toch bijna nul is op een SSD kost het ook geen extra tijd om een gefragmenteerde page op te halen als een LBA read gedaan wordt. Dit soort dingen wil je juist op een dedicated RT CPU doen en niet time-shared in een draadje in een driver in een kernel in een user-OS.

falcon1 @johnkeates • 26 mei 2014 09:56

Het probleem is echter dat een SSD firmware realtime I/O moet verzorgen, iets wat een time-sharing OS niet kan... zelfs met RTOS firmware op SSD's heb je nog dat programma's iowait en blocking status krijgen om dat ze op storage moeten wachten.

Binnen één schrijf cyclus heb je idd RTIO nodig. Verder niet. Het zelfde geld voor RAM. En hoeveel firmware zie je daar? Hoeveel heb je nodig? De uitgebreide firmware is leuk voor "legacy" support. Oftewel software die er niet de aanpassing heeft voor nieuwe hardware typen. Closed source software meestal dus.

Die "iowait" en "blocking" is eigenlijk het resultaat van een SSD die zich voordoet als een roterende schijf en z'n specs pimpt. En doordat allerlei "middle-ware" elkaar in de weg zit, buffers, caching, timing. En ze niet of nauwelijks op elkaar af te stemmen zijn.

Uiteindelijk kun je alleen vanuit je software bepalen welke data er wel handig is om te bufferen en welke niet. En dat hangt ook nog eens af van hoe je die gebruikt. Nu heb je allerlei onderdelen die "automatisch" afstellen, maar geen onderling contact hebben over wie en wat.

Ik zie dat de opslag systemen steeds complexer worden. NAS, SAN, Shared Storage. En er steeds meer onverklaarbare performance problemen, datacorruptie etc. ontstaan, die nauwelijks te achterhalen zijn. En alle fabrikanten wijzen naar elkaar. Het zit in jouw hardware, nee in jouw software, nee in jouw firmware, nee in de jouwe. etc. etc.

Vervolgens zit je als Cloud provider maanden met een nauwelijks te reproduceren probleem die niemand wil oplossen. En een ontevreden klant.

De complexiteit van software groeit harder dan de hardware versnelt. Allerlei onafhankelijke stukken software op elkaar "plakken" die niet expliciet samenwerken is een doodlopende weg.

Ik heb ook vaak genoeg gezien dat een RAID set "netjes" en nieuwe schijf in de set op nam na een het uitwisselen van een kapotte en dat de database toch fijn ergens corrupt was geraakt. Op een plek die pas na het verstrijken van je back-ups tegen kwam.

Bovendien is al die uitgebreide firmware ook niet "eco" vriendelijk. Je propt eigenlijk nog een extra computer in je computer om al die firmware te draaien, die eigenlijk van alles doet waar je misschien wat aan hebt.

Fireshade @Verwijderd • 23 mei 2014 17:20

Denk bijvoorbeeld aan de compatibiliteit; je kunt dan je SSD alleen maar uitlezen op Windows PCs met die scrambler software/drivers geïnstalleerd.

Ik denk dat je het verkeerd begrijpt. De LBA-scramber dient alleen om het schrijven te versnellen.

Als ik het goed begrijp, gebeurt het volgende:
De LBA scrambler kijkt naar gefragmenteerde pages op de SSD die op het punt staan gewist te worden door de garbage collection. Het kijkt welke cellen overeenkomen en welke niet overeenkomen met de te schrijven data. Als dat bepaald is, wordt opdracht gegeven alleen die cellen in de page te overschrijven die niet overeenkomen. Hierdoor wordt dus ongeveer 55% bespaard op schrijfacties.
Maar als de data eenmaal op de SSD geschreven is, dan staat het er gewoon op en heb je helemaal geen LBA scrambler nodig om uit te lezen.

diederikhu @Verwijderd • 23 mei 2014 17:00

Dit soort onderzoeken zijn niet noodzakelijk voor het belang van gebruikers. Dergelijke onderzoeken kunnen ook simpelweg als proof of concept te dienen, om van daaruit de technieken te verbeteren en mogelijk meer toepasbaar te maken voor algemener gebruik.

TheekAzzaBreek @Verwijderd • 23 mei 2014 18:00

Er is helemaal niet gezegd dat de LBA scrambler een aparte software laag wordt (of heb je daar een bron voor ?). Het lijkt me een stuk waarschijnlijker dat het uiteindelijk als algoritme aan de ssd firmware toegevoegd zal worden.

De stapjes die jij beschrijft zijn eigenlijk al standaard in een ssd. Het door het filesysteem gekozen LBA (NB: Logical Block Address) wordt door de firmware vertaald naar fysiek blokken en pages, waar al allerlei optimalisatielogica aan te pas komt. Dito voor RAID arrays. Zelfs een losse HDD doet het, in geval van bad sectors. Niets nieuws onder de zon wat dat betreft.

ToFast 23 mei 2014 16:41

Is de LBA scrambler-middleware dan gewoon eigenlijk software/firmware, omdat het ook op bestaande SSD's toegepast kan worden?

diederikhu @ToFast • 23 mei 2014 16:52

"Because, with the new method, it is not necessary to make any changes to NAND flash memory, and the method is completed within the middleware, it can be applied to existing SSDs as it is."

Volgens het artikel wel.

EDIT: Ik had de reactie van ToFast verkeerd gelezen, zijn vraag was of het software/firmware is, maar de quote uit het artikel maakt dat niet duidelijk. Ik had vernomen dat zijn vraag luidde of het op bestaande SSD's toegepast worden, niet in welke vorm de middleware beschikbaar wordt gesteld.

[Reactie gewijzigd door diederikhu op 22 juli 2024 14:50]

JW1

@diederikhu • 23 mei 2014 17:06

Maar volgens het boek 'Marketing voor beginners' kan je het beter toepassen als nieuwe techniek, tenzij de concurrent het wel implementeert.

Iblies @JW1 • 23 mei 2014 17:13

Waarschijnlijk zijn het dan technici ipv marketeers.

_Eend_ @Iblies • 24 mei 2014 07:54

Maar over het algemeen beslissen de marketeers/management over features, niet de engineers..de engineers implementeren de features

elloco999 @_Eend_ • 26 mei 2014 10:33

En in dit geval betreft het onderzoekers (technische, niet financiele mensen) die de resultaten van hun onderzoek publiceren. Het betreft hier dus wel degelijk engineers.

En ik vermoed dat deze onderzoekers graag willen dat zoveel mogelijk fabrikanten hun techniek in licentie nemen, dus het is in hun voordeel om de mensen te laten weten dat dit ook op bestaande SSD's kan worden toegepast. Dan willen mensen dat graag hebben en worden de fabrikanten onder druk gezet om deze techniek in een firmware update (vermoedelijk, wordt niet duidelijk uit de tekst) te implementeren. En daarvoor hebben ze dan weer de eerder genoemde licentie nodig...

Het is natuurlijk wel zo dat de marketeers/ het management van die fabrikanten er voor kan kiezen de techniek alleen in nieuwe SSD's te implementeren, om zo meer nieuwe SSD's te verkopen.

[Reactie gewijzigd door elloco999 op 22 juli 2024 14:50]

Titan_Fox @ToFast • 23 mei 2014 17:20

Fabrikanten willen veel liever dat je iedere keer een nieuwe SSD koopt. Door dergelijke technieken toe te passen zullen ze zichzelf in de vingers snijden. Het is afwachten tot een van de fabrikanten toch voor de pragmatische aanpak kiest door deze "scrambler" te implementeren. Als ze het marketingtechnisch handig aanpakken zouden ze zich daarmee kunnen onderscheiden van andere merken, waardoor deze zich op den duur ook genoodzaakt zien om LBA-scramblers te gebruiken.

Ventieldopje @Titan_Fox • 23 mei 2014 20:28

Dat vind ik wat kort door de bocht, het is mooie marketing voor die fabrikant? Een snelheidsverhoging van 300%, minder energieverbruik etc. is voor iedereen mooi. Die technologie kost ze niks, stoppen het in een nieuwe productlijn met een hogere prijs en na een tijd maken ze daar gewoon weer een mainstream lijn van.

Ze kunnen er dan mooi geld op verdienen omdat veel mensen niet technisch zijn en niet zouden weten hoe ze de firmware van een SSD zouden kunnen updaten, laat staan dat ze het zouden durven. Al is het niet omdat fabrikanten dan garantie zouden kunnen gaan weigeren bijvoorbeeld.

Teijgetje @Ventieldopje • 24 mei 2014 21:25

Dat vind ik wat kort door de bocht, het is mooie marketing voor die fabrikant?

Zoals Titan_Fox al zegt, de eerste fabrikant die dit implementeert in zijn firmware voor reeds in gebruik zijnde SSD`s krijgt daar van de gebruikers flink kudo`s voor.
En waarschijnlijk een reden om bij dat merk te blijven.
Pure marketing.....

Die technologie kost ze niks

Het is geen technologie, het is software.
De technologie kost inderdaad niets omdat die er niet is, wat een softwarelicentie kost is een ander verhaal.
Maar dit lijkt me wel een gevalletje FRAND.

Ze kunnen er dan mooi geld op verdienen omdat veel mensen niet technisch zijn en niet zouden weten hoe ze de firmware van een SSD zouden kunnen updaten, laat staan dat ze het zouden durven. Al is het niet omdat fabrikanten dan garantie zouden kunnen gaan weigeren bijvoorbeeld.

Ik vraag me af of je zelf een SSD gebruikt?
De meeste fabrikanten leveren een tool om de SSD te optimaliseren, onderhouden, checken EN te updaten, als in firmware flashen.
Waarbij je natuurlijk je garantie behoudt.

Mijn beide Intel 320`s (600 en 320 GB) hebben al tig updates gehad.......met een paar muisklikken. (klik1; via de tool naar hun site om te kijken of er een firmwareupdate is en die eventueel downloaden, klik2 ; in de tool firmware updaten)
En hebben beide volgens de tool nog een 100% levensduur.

Hopelijk implementeert Intel deze LBA scrambler in de nabije toekomst ook voor de oudere SSD`s.
Iets wat alle fabrikanten zouden moeten doen natuurlijk als de winst zo groot is, zowel voor eigen product, als voor het milieu door de lagere energiekosten.
Waarbij je als fabrikant mooi die milieukaart kan trekken in je marketing.....

Knap werk van die Japanners. $_/-\o_$ .

[Reactie gewijzigd door Teijgetje op 22 juli 2024 14:50]

KaiZas @ToFast • 23 mei 2014 16:48

Dat zou mogelijk zijn, peins ik. Maar where's the profit in that?

DeEchteKwartel @KaiZas • 23 mei 2014 16:59

Dat is inderdaad het jammere, maar het zou super tof zijn als het werd toegepast!

i-chat @ToFast • 23 mei 2014 16:52

en ook redelijk interessant op wat voor termijn gaan we dit zien, en, zal het aan bedrijven liggen, of zullen er software libs beschikbaar komen, als ik afhankelijk ben van samsung of kingston zullen mijn ssds wel nooit hiervan worden voorzien en kan ik dus mooi nieuwe kopen...

M.l. @ToFast • 23 mei 2014 18:10

Het idee of de uitvinding kan als hardware in een ssd-controller of ssd ingebouwt worden, maar je kan dit natuurlijk ook veranderen in de firmware, al zal dat lang niet bij iedere ssd kunnen en zal het waarschijnlijk minder snel zijn dan bij de hardware-implementatie.

CoreIT 23 mei 2014 16:54

Interessant en mogelijk nuttig. Persoonlijk, als audioproducent, heb ik er echter helemaal niets aan en zou ik eindeloos veel blijer zijn met een sterke toename in leessnelheid i.p.v. schrijfsnelheid. Leessnelheid kan nooit hoog genoeg; tja ach bus-limits en zo helaas. Write-once, read infinite. Maar bovenal zou geen nieuws zo goed zijn als sterke prijsdaling voor SSDs.

-EDIT: ja downvote maar vooral weer. Het gaat ook helemaal niet over SSD en het is natuurlijk vollédig offtopic. Verder bevat mijn bericht haatdragende taal en heeft het een ronduit racistische strekking.. Foei Core! Owee, owee jij zult vanuit je vakgebied geen énig signaal geven eens liever verbetering te zien in leessnelheid en prijsdaling. Evenmin zul jij ook maar enig licht werpen op dat dit voor jouw vakgebied niet relevant is; stel je voor zeg! Nu ga maar snel heen Core, héén zei ik je, en welnu! DOWNVOTE DOWNVOTE, snel snel, dit is Tweakers, hier is geen plaats voor nette, on-topic berichten!

[Reactie gewijzigd door CoreIT op 22 juli 2024 14:50]

dbox2 @CoreIT • 23 mei 2014 22:10

Check fusion io eens..... En mss de juiste io scheduler instellen.

Verwijderd 23 mei 2014 22:53

Een moois stukje nieuws op het gebied van deze tecnologie en dit is zeker een interessante ontwikkeling.

Ik kijk alvast uit naar de komende SSD's die hier gebruik van gaan maken en als het niet veel duurder zal zijn in verhouding tot de toch al zeer lage prijzen van de huidige SSD's dan kan er een test exemlaar besteld worden.

Verwijderd 25 mei 2014 14:36

De essentie van het LBA-scrambler concept is niet volledig nieuw. De gangbare sectorgrootte van een harddisk is 512 bytes. De meest gebruikte clustergrootte is 4K. Dus als je 1 byte op disk wilt wijzigen dan wordt de hele 4K cluster herschreven. Voor een HDD maakt dat niets uit, maar voor een SSD is dat fataal voor de levensduur.

Er bestaan al programma's die zinloze writes naar SSD blokkeren. Een voorbeeld is PrimoCache. Dat is een disk cache met een extra. Als het OS een blok data schrijft en dat even later weer wist, dan herkent PrimoCache dat en gooit het blok uit zijn RAM cache weg zonder de write naar de SSD te sturen. Dat is al een vorm van optimalisatie, dat veel zinloze SSD writes voorkomt. Overigens is PrimoCache een filesystem driver onder Windows, waar Romex Software al jaren aan ontwikkelt. Het is erg complex en er waren vele beta-versies, maar het is nu uit beta en in productie.

Meer in de lijn van LBA-scrambling experimenteerde OCZ in het verleden met een RAM buffer waarin dirty sectors werden bewaard totdat er genoeg dirty data was om een compleet flash block te wissen/herschrijven. Dat werkte goed omdat NAND blocks 4K waren, evenals de default clustergrootte van b.v. NTFS. Daar was veel administratie voor nodig, want je blijft altijd met incomplete tijdelijke RAM blocks zitten. Bijvoorbeeld als het OS maar 1 byte in een cluster wijzigt en dan nooit meer, dan zit je met een incompleet RAM buffer block. Ik weet niet hoe ze dat hebben opgelost. Maar het concept werkte. Overigens heeft OCZ dit niet als leuke optimalisatie verzonnen, maar uit noodzaak omdat de NAND writes zonder de RAM buffer tergend traag waren en talloze zinloze rewrites opleverde.

Ik denk dat LBA-scrambling een soort verbetering van het OCZ RAM-buffer concept is. Als je namelijk op byte-niveau kan optimaliseren dan ben je niet meer gebonden aan de fysieke afmetingen van sectors en clusters. Want die wijzigen namelijk geregeld, b.v. HDD's krijgen steeds vaker fysieke sectoren van 4K.

Omdat de industrie geen zin heeft in een nieuw filesystem en een nieuwe flash block layout, zullen we nog vele jaren met de opvolger van head/sector/track zitten, namelijk LBA. Als LBA-scrambling werkt en de industrie ziet er brood in, dan zie ik dit als de zoveelste vooruitgang. Ik denk dat het niet gebruikt zal worden om de levensduur van SSD's te verlengen, maar om nog kleiner NAND te kunnen gebruiken zonder dat de levensduur terugloopt. Want kleiner NAND = eerder kapot.

Blazing-Studios 23 mei 2014 16:47

het aantal write/erase-cycli aanzienlijk kunnen verlagen, dat wil je toch juist zo hoog mogelijk hebben of ben ik nou gek (disclaimer: ja ik ben gek

)

cyberstalker @Blazing-Studios • 23 mei 2014 16:53

Hoe hoger de cycli, hoe sneller je schijf verslijt. Dus lijkt me dat de meeste mensen daar niet zo blij van zullen worden. De truc is juist om met zo min mogelijk cycli zo snel mogelijk data te verwerken.

Blazing-Studios @cyberstalker • 23 mei 2014 16:57

Wacht ik snap hem, ik dacht dat het er om ging hoe veel cycli tot de ssd de geest gaf

(vrijdagmiddag zullen we maar de schuld geven)

TheekAzzaBreek @cyberstalker • 23 mei 2014 17:50

Doordat ssd's in vrij grote blokken schrijft, wordt er fysiek meer geschreven dan er aan data aangeleverd wordt, dat heet write amplification. Als je de verhouding beschreven blokken / data kan verhogen is dat juist goed voor de snelheid en de levensduur. Je wil de data doorvoer zo hoog mogelijk hebben en de write/erase cycli zo laag mogelijk

Zer0 @Blazing-Studios • 23 mei 2014 17:25

Hierdoor wordt het aantal benodigde write/erase-cycli verlaagd.
Die wil je juist omlaag brengen om de levensduur te verhogen.

Verwijderd @Zer0 • 23 mei 2014 18:03

yep. garriej gaat liever 3x rechtsaf op een rotonde i.p.v. 1x linksom ;p

Op dit item kan niet meer gereageerd worden.

Lees meer

Reacties (38)

Sorteer op:

Weergave: