Re: Compact Flash vs. Solid State Disk [Re: Spaß mit BIOS-Disk-Geometrien]

From: Bernd Walter <ticso(at)cicely12.cicely.de>
Date: Fri, 20 Apr 2007 11:58:57 +0200

On Fri, Apr 20, 2007 at 09:19:37AM +0200, Oliver Fromme wrote:
> Oliver Lietz wrote:
> > Empfehlen sich Solid State Disks eher [*] als richtiger Festplattenersatz oder
> > tut sich da im Vergleich zu herkömmlichem Compact Flash nicht viel?
> >
> > http://www.amazon.de/*/dp/B000KLKX60/
> > http://www.heise.de/newsticker/meldung/83173
> >
> > [*] Preis und Kapazität mal außer Acht gelassen
>
> Ob sich die empfehlen, hängt von Deinen persönlichen Anfor-
> derungen ab. Eine generelle Empfehlung gibt es nicht.
>
> Vorteil einer solchen Flashdisk ist natürlich die geringe
> Hitze-, Vibrations- und Geräuschentwicklung sowie die Un-
> empfindlichkeit gegen Stöße und Vibrationen. Nachteil ist
> die begrenzte Zahl der Schreibzyklen -- die hat sich bei
> Flash-Speichern zwar in letzter Zeit weiter gebessert, aber
> für einen Fileserver wäre eine Flashdisk immer noch voll-
> kommen ungeeignet.
>
> Übrigens wehre ich mich ein bisschen gegen die irreführende
> Bezeichnung SSD (Solid-State-Disk). Die Teile unter den
> o.g. Links würde ich als Flashdisks bezeichnen, nicht als
> SSDs. Das ist mal wieder so ein Fall, wo ein älterer Be-
> griff für eine neue, unterschiedliche Technologie gekapert
> wird.

SSD ist sicherlich nicht falsch und bezeichet wohl eher den
Umstand, dass das Medium nicht entnehmbar ist.
Aber Flashdisk wäre in der Tat viel treffender.

> SSDs kamen vor ca. 20 Jahren in Mode -- das waren Disks,
> die aus RAM-Chips bestanden (in einem Festplattengehäuse
> mit SCSI-Interface o.ä.). Am Anfang wurden SRAM-Chips
> verwendet. Vorteil ist, dass die extrem schnell sind
> (die heutigen Flashdisks, auch die unter o.g. Links,
> finde ich eigentlich nicht ausgesprochen schnell), ihren
> Inhalt auch ohne Stromversorgung behalten, und im Gegen-
> satz zu Flash einzeln adressierbar sind und eine praktisch
> unbegrenzte Lebensdauer haben. Nachteil war der Preis.
> Daher ging man später dazu über, in SSDs übliche DRAM-
> Chips zu verbauen, die erheblich preiswerter waren, und
> ihnen einen Batterie-Puffer zu verpassen. Sowas gibt es
> übrigens auch heute noch zu kaufen. Es gab (und gibt) auch
> Hybridlösungen, wo die Daten nach dem Ausschalten auf eine
> normale Platte zurückgespeichert werden, so dass nur eine
> relativ kleine Pufferbatterie genügt -- sozusagen eine
> Platte, bei der der eingebaute Cache so groß ist wie die
> Plattenkapazität. Wohlgemerkt, alles mit schnellem und
> langlebigem DRAM, kein Flash. Eine einzige solche Platte
> kann die theoretische Bandbreite eines SCSI-Busses satu-
> rieren (320 MB/s bei U320-SCSI); in der Praxis ist es auf-
> grund diverser Overheads weniger.

Batterie-Puffer brauchen auch SRAM Chips, allerdings aufgrund der
Tatsache, dass die keinen Refresh brauchen kommen die mit deutlich
weniger Strom aus, als DRAM, sodass man hier je nach Speichergröße
mit Lithiumzellen und ähnlichem arbeiten kann.

> Ich sehe daher Flashdisks eher als eine Art »Poor man's
> SSD«. Ist vielleicht auch nur eine Modeerscheinung, oder
> eine Folge der Tatsache, dass die Preise von Flashchips
> in letzter Zeit erheblich stärker gefallen sind als die
> von DRAMs.
>
> Ein Vorteil, den alle Disks ohne bewegliche Teile gemeinsam
> haben, ist natürlich der, dass die Seektimes praktisch Null
> sind. Diesen Vorteil spürt man vor allen Dingen dann, wenn
> man Anwendungen mit viel (auch parallelen) Random-Access
> hat. Bei RAM-basierten SSDs gilt das sowohl fürs Lesen als
> auch fürs Schreiben, bei Flash-basierten Disks dagegen eher
> nur für das Lesen.

Die Geschwindigkeiten der NAND-Flash sind inzwischen auch nicht mehr
ohne - erst recht wenn ein Gerät so viele Chips davon vereint, womit
sich die Geschwindigkeit bündeln liesse, wobei ich denke, dass das
in den aktuellen geräten aus preislichen Gründen nicht passiert.
Das kommt zwar, vor allem beim schreiben, nicht an RAM ran, aber
ist denoch recht nett und kann auch linear durchaus schneller als eine
HDD sein.

Problematisch ist die NAND-Technology aber durchaus, vor allem wegen
der Anfälligkeit auf Inkonstenzen.
So handelt es sich um Flash Chips, die immer einen ganzen Block
behandeln, der bei den heute üblichen Chips bereits 2k plus CRC
groß ist.
Wenn man nun übliche 512 Byte Blöcke schreibt macht der Controller
daraus einen read-modify-write Zugriff auf's Flash.
Wenn jetzt der Strom zum falschen Moment ausfällt hat man eine
defekte CRC in dem Datenblock - und nicht nur in dem, sondern auch
in allen anderen, die im gleichen 2k Block liegen, also auch in
Daten, die schon vor langer Zeit geschrieben wurden.
Deshalb benutze ich beim newfs für Flash Medien inzwischen auch eine
Fragmentgröße von 2k und der Wechsel zu 4k ist bereits absehbar - mit
Platz knausern muss man ja zum Glück nur noch sehr selten.
Ein Wert, den einen der Hersteller selten nennt...

NAND-Flash sind in 2 Bereiche aufgeteilt - ein kleiner Teil der Zellen
hat eine viel höhere Anzahl Schreibzyklen, als der Rest und zudem als
fehlerfrei getested werden.
Dort verwalten die Controller-Chips ihre Verwaltungtabellen, da die
Speicherblöcke nämlich rotiert werden müssen und man bisweilen auch
Ersatz braucht.
Ebenfalls dort vorhanden sind die Defekttabellen vom Flash Hersteller,
die Chips sind nämlich nur deshalb so viels günstiger als DRAM, weil
diese keineswegs fehlerfrei sind.
Das Problem mit diesem Bereich ist, dass auch hier regelmässige Update
stattfinden und es auch hier zu konsistenzproblemem führen kann.
Vor allem wenn mal die CRC zu einem dieser Verwaltungsblöcke defekt
ist, dann ist nämlich plötzlich ein sehr großer Datenbereich des
Mediums nicht mehr lesbar.
Die Umgangsweise mit diesem Vewaltungsbereich benennt kein mir bekannter
Hersteller - bestenfalls finded man das noch im Datenblatt des
Controllers, den man erst durch öffnen identifizieren kann.

Es ist kein Geheimniss, dass das Power-cyclen eines Flash basierten
Gerätes, welches gerade schreibt, ein echtes Risiko darstellt und das
eben nicht nur für die gerade beschriebenen Dateien.
Ich hatte schon einen Fall gehabt, wo nach einem Powercycle beim
Schreiben von Logfiles nachher die ld.so nicht mehr lesbar war.
So langsamm sind die Medien groß genug, dass man sich Gedanken über
Partitionierung zur Fehlerisolation machen sollte.
Dann hat man ein geringeres Risiko, dass sich der beschriebene Teil mit
den Systemkritischen die Verwaltungsblöcke teilt.
UFS hingegen versucht das ja in Hinblick auf echte Festplatten, auf dem
Medium gleichmässig zuverteilen.

-- 
B.Walter                http://www.bwct.de      http://www.fizon.de
bernd(at)bwct.de           info(at)bwct.de            support(at)fizon.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Fri 20 Apr 2007 - 12:00:43 CEST

search this site