Wat maakt eMMC-flashgeheugen mogelijk in mobiele apparaten, maar niet in pc's?
Het gebruik van het flash-geheugen voor het uitvoeren van een desktopsysteem, zoals Windows, werd al geruime tijd afgeraden. Maar wat maakte het tot een wenselijke en haalbare optie voor mobiele apparaten? De SuperUser Q & A-post van vandaag heeft het antwoord op de vraag van een nieuwsgierige lezer.
De Question & Answer-sessie van vandaag komt tot ons dankzij SuperUser - een onderdeel van Stack Exchange, een gemeenschapsgedreven groep van Q & A-websites.
De vraag
SuperUser-lezer RockPaperLizard wil weten wat eMMC-flashgeheugen mogelijk maakt op mobiele apparaten, maar niet op pc's:
Sinds USB-flashdrives zijn uitgevonden, hebben mensen zich afgevraagd of ze hun besturingssystemen op hen konden gebruiken. Het antwoord was altijd "nee" omdat het aantal benodigde schrijfbewerkingen voor een besturingssysteem ze snel zou verslijten.
Naarmate SSD's populairder zijn geworden, is de technologie voor slijtage-nivellering verbeterd, zodat besturingssystemen daarop kunnen draaien. Verschillende tablets, netbooks en andere slanke computers gebruiken flash-geheugen in plaats van een harde schijf of SSD en het besturingssysteem is erop opgeslagen.
Hoe werd dit opeens praktisch? Implementeren ze meestal bijvoorbeeld wear-leveling-technologieën?
Wat maakt eMMC-flashgeheugen mogelijk op mobiele apparaten, maar niet op pc's?
Het antwoord
SuperUser-bijdragers Speeddymon en Journeyman Geek hebben het antwoord voor ons. Ten eerste, Speeddymon:
Alle flashgeheugenapparaten, van tablets tot mobiele telefoons, slimme horloges, SSD's, SD-kaarten in camera's en USB-thumbdrives maken gebruik van NVRAM-technologie. Het verschil zit in de NVRAM-architectuur en hoe het besturingssysteem het bestandssysteem aankoppelt op elk opslagmedium waarop het zich bevindt.
Voor Android-tablets en mobiele telefoons is de NVRAM-technologie gebaseerd op eMMC. De gegevens die ik over deze technologie kan vinden, suggereren tussen schrijfcycli van 3 tot 10 k. Helaas is niets van wat ik tot nu toe heb gevonden definitief, omdat Wikipedia niets zegt over de schrijfcycli van deze technologie. Alle andere plaatsen die ik heb bekeken, waren verschillende fora, dus nauwelijks wat ik een betrouwbare bron zou noemen.
Ter vergelijking, de schrijfcycli op andere NVRAM-technologie zoals SSD's, die NAND- of NOR-technologie gebruiken, liggen tussen 10k en 30k.
Nu, met betrekking tot de keuze van het besturingssysteem om het bestandssysteem te mounten. Ik kan niet spreken over hoe Apple het doet, maar voor Android is de chip gepartitioneerd zoals een harde schijf dat zou zijn. U hebt een besturingssysteempartitie, een gegevenspartitie en verschillende andere partities met eigendomsrechten, afhankelijk van de fabrikant van het apparaat.
De echte rootpartitie leeft in de bootloader, die samen met de kernel wordt gebundeld als een gecomprimeerd bestand (jffs2, cramfs, etc.), dus als de fase 1-opstartprocedure van het apparaat is voltooid (meestal het logo van de fabrikant), dan is de kernel boots en de rootpartitie worden tegelijkertijd als RAM-schijf gemount.
Terwijl het besturingssysteem opstart, wordt het bestandssysteem van de primaire partitie (/ systeem, dat jffs2 is op apparaten vóór Android 4.0, ext2 / 3/4 op apparaten sinds Android 4.0 en xfs op de nieuwste apparaten) als alleen-lezen gekoppeld. dat er geen gegevens naar geschreven kunnen worden. Dit kan natuurlijk worden uitgevoerd door het zogenaamde "rooten" van uw apparaat, dat u toegang geeft als een supergebruiker en u toestaat om de partitie opnieuw te koppelen als lezen / schrijven. Uw "gebruikers" -gegevens worden naar een andere partitie op de chip geschreven (/ data, die dezelfde conventie volgt als hierboven op basis van de Android-versie).
Met steeds meer mobiele telefoons die SD-kaartsleuven gebruiken, zou je denken dat je de schrijffase eerder zult bereiken omdat al je gegevens nu worden opgeslagen in eMMC-opslag in plaats van een SD-kaart. Gelukkig detecteren de meeste bestandssystemen een mislukte write naar een bepaald opslaggebied. Als een schrijf mislukt, worden de gegevens geruisloos opgeslagen in een nieuw opslaggebied en wordt het slechte gebied (ook wel een slecht blok genoemd) afgezet door het bestandssysteemstuurprogramma zodat de gegevens daar in de toekomst niet meer worden geschreven. Als een leesbewerking mislukt, worden de gegevens als corrupt gemarkeerd en wordt de gebruiker verteld een bestandssysteemcontrole uit te voeren (of schijfcontrole), of controleert het apparaat automatisch het bestandssysteem tijdens de volgende keer opstarten.
In feite heeft Google een patent voor het automatisch detecteren en verwerken van slechte blokken: Slechte blokken beheren in het flashgeheugen voor elektronische gegevensflashkaarten
Om meer ter zake te brengen, is uw vraag over hoe dit opeens praktisch werd, niet de juiste vraag. Het was nooit onpraktisch in de eerste plaats. Het werd ten zeerste afgeraden om een besturingssysteem (Windows) op een SSD te installeren (vermoedelijk) vanwege het aantal schrijfbewerkingen op een schijf.
Het register ontvangt bijvoorbeeld letterlijk honderden lees- en schrijfbewerkingen per seconde, wat te zien is met de Microsoft-SysInternals Regmon Tool.
Het installeren van Windows werd afgeraden op SSD's van de eerste generatie omdat bij het ontbreken van slijtage-nivellering de gegevens die naar het register werden geschreven elke seconde (waarschijnlijk) uiteindelijk door early adopters werden ingehaald en resulteerden in niet-opstartbare systemen als gevolg van registercorruptie.
Met tablets, mobiele telefoons en vrijwel elk ingebed apparaat is er geen register (uiteraard zijn Windows Embedded-apparaten uitzonderingen) en er is dus geen reden om gegevens voortdurend naar dezelfde delen van het flashmedium te schrijven..
Voor Windows Embedded-apparaten, zoals veel van de kiosks die worden aangetroffen op openbare plaatsen (zoals Walmart, Kroger, enz.), Waar van tijd tot tijd een willekeurige BSOD kan worden weergegeven, is er niet veel configuratie die kan worden gedaan omdat ze zijn vooraf ontworpen met configuraties die bedoeld zijn om nooit te veranderen. De enige keer dat er wijzigingen plaatsvinden, is voordat de chip in de meeste gevallen wordt geschreven. Alles dat moet worden opgeslagen, zoals uw betaling aan de supermarkt, wordt gedaan via het netwerk naar de databases van de winkel op een server.
Gevolgd door het antwoord van Journeyman Geek:
Het antwoord was altijd "nee" omdat het aantal benodigde schrijfbewerkingen voor een besturingssysteem ze snel zou verslijten.
Ze werden uiteindelijk kosteneffectief voor regulier gebruik. Dat "dragen" de enige zorg is, is een beetje een veronderstelling. Er zijn al geruime tijd systemen met Solid State Memory aan het lopen. Veel mensen die auto-puters bouwden, startten op CF-kaarten (die elektrisch compatibel waren met PATA en triviaal te installeren in vergelijking met PATA-harde schijven), en industriële computers hadden kleine, robuuste flash-opslag.
Dat gezegd hebbende, waren er niet veel opties voor de gemiddelde persoon. Je zou een dure CF-kaart en een adapter voor een laptop kunnen kopen, of een kleine, zeer dure industriële schijf op een module-eenheid voor een desktop kunnen vinden. Ze waren niet erg groot in vergelijking met hedendaagse harde schijven (moderne IDE DOM's met een top van 8GB of 16GB denk ik). Ik ben er vrij zeker van dat je solid state-systeemstations had kunnen installeren, lang voordat standaard SSD's gewoon werden.
Er zijn voor zover ik weet geen echte universele / magische verbeteringen in de slijtage-egalisatie geweest. Er zijn stapsgewijze verbeteringen geweest, terwijl we van pricy SLC naar MLC, TLC en zelfs QLC zijn gegaan, samen met kleinere procesgroottes (allemaal lagere kosten met een hoger risico op slijtage). Flash is een stuk goedkoper geworden.
Er waren ook een paar alternatieven die geen slijtageproblemen hadden. Bijvoorbeeld, het hele systeem draaien van een ROM (dat is waarschijnlijk een solid-state opslag) en RAM met een batterij-back-up, waarmee veel vroege SSD's en draagbare apparaten zoals de Palm Pilot werden gebruikt. Geen van deze zijn tegenwoordig gebruikelijk. Harde schijven schommelden in vergelijking met bijvoorbeeld RAM-geheugen met batterij (te duur), apparaten met vroege solid-state (enigszins prijzig) of boeren met vlaggen (nooit gevangen vanwege de verschrikkelijke gegevensdichtheid). Zelfs het moderne flash-geheugen is een afstammeling van snel wissende eeproms en eeproms zijn gebruikt in elektronische apparaten voor het opslaan van dingen als firmware voor eeuwig gebruik.
Harde schijven bevonden zich eenvoudig op een mooie kruising van hoog volume (wat belangrijk is), lage kosten en relatief voldoende opslagruimte.
De reden dat u eMMC's aantreft in moderne, low-end computers, is dat de componenten relatief goedkoop, groot genoeg zijn (voor desktopbesturingssystemen) voor die kosten en gemeenschappelijkheid delen met mobiele telefooncomponenten, dus worden ze in bulk geproduceerd met een standaardinterface. Ze geven ook een grote opslagdichtheid voor hun volume. Gezien het feit dat veel van deze machines een schamele 32 GB of 64 GB hebben, vergelijkbaar met harde schijven uit het betere deel van een decennium geleden, zijn ze een verstandige optie in deze rol.
We komen eindelijk op het punt dat je een redelijke hoeveelheid geheugen betaalbaar en met redelijke snelheden op eMMC's en flash kunt opslaan, dat is waarom mensen voor ze gaan.
Heb je iets toe te voegen aan de uitleg? Geluid uit in de reacties. Wilt u meer antwoorden van andere technisch onderlegde Stack Exchange-gebruikers lezen? Bekijk hier de volledige discussiethread.
Image Credit: Martin Voltri (Flickr)
