Re: FreeBSD auf SSD

On Tue, Feb 01, 2011 at 01:40:32PM +0100, Oliver Fromme wrote:
> Bernd Walter wrote:
> > Matthias Fechner wrote:
> > > Oliver Fromme wrote:
> > > bei einer Intel SSD ist das nicht notwendig. Die 160GB Version hat
> > > intern 200GB und damit 40GB Reserve fest eingebaut.
>
> Das ist kein Argument; _jede_ SSD (und auch jede herkömmli-
> che Festplatte) hat eine deutlich größere Bruttokapazität
> im Vergleich zur nutzbaren Kapazität. Bernd hat das ja
> schon sehr ausführlich erklärt. Dieser Platz wird für Ver-
> waltungsaufgaben, Bad-Block-Remapping und zur Beschleuni-
> gung von Schreibzugriffen verwendet (z.B. Pre-Erase). Der
> Sandforce-Controller zum Beispiel, der in den OCZ-Vertex2E
> verbaut ist, verwendet einen Teil des zusätzlichen Platzes
> zur Zwischenspeicherung des komprimierten Datenstroms beim
> Schreiben, was mit zur hohen Burst-Schreibgeschwindigkeit
> dieser SSDs beiträgt (bis knapp an das SATA-3G-Limit).

Man baut 200GB ein und bekommt 160GB netto.
20% sind also Verlust.
Am leichtesten kann man das mit kleinen SD und CF Medien erkennen.
Ein 4G Medium hat in der Regel echte 4GB Flash drin.
Das sind 4294967296 Bytes.
80% davon sind 3435973836 Bytes, also 3,2 echte GB, aber im
für den Hersteller sind das Marketingmässig 3,4GB.
Ein konkretes Trancend 4G CF Medium hat z.B. 4009549824 Bytes.
Man erkennt deutlich, dass da weniger freigehalten wurde, nämlich gerade
mal 7%, was sicherlich damit zu tun hat, dass die das Medium noch
Werbewirksam als 4GB verkaufen wollen.

> Mal eine kleine Rechenaufgabe: OCZ gibt für seine MLC-
> basierten SSDs mindestens 10000 PECs (Program-Erase-Cycles)
> an. Bei 120 GB Kapazität bedeutet das, dass man während
> der gesamten Lebenszeit mindestens 1200 TB auf die SSD
> schreiben kann. Wenn man ununterbrochen 200 MB/s darauf
> schreibt (das Maximum, das sie kontinuierlich schafft),
> würde sie somit etwa zwei Monate halten. Das klingt sehr
> kurz, ist aber auch ein unrealistischer Anwendungsfall.

Ja - unter Einbeziehung der CRC und die ist bei MLC deutlich
umfangreicher, um die eh schon deutlich geringere Zuverlässigkeit
zu garantieren.
Ohne CRC kann man ohnehin gar nichts garantieren, aber das ist bei
Festplatten letzlich auch nicht anders.

> Wer sich trotzdem noch Sorgen macht, muss dann halt zu
> SLC statt MLC greifen (bei OCZ wäre das z.B. die "EX"-
> Reihe), die zehnfach höhere PECs haben. Aber der Preis
> dafür liegt dann auch ungefähr einen Faktor 10 höher.
> »You get what you pay for«, wie es so schön heißt.

Es kommt halt auf die Aufgabe an.
Bei einem ZFS Cache sollte man lieber die 10fache Kapazität
kaufen (reduziert nebenbei ja auch den Verschleiss) und den
größeren Cache geniessen - wenn es denn trotzdem man knallt,
dann ist halt Cachinhalt weg, was keinen stört.

> > Wer meint wichtige Daten auf MLC zu speichern, sollte sich bei 5000
> > Schreibzyklen Gedanken machen.
>
> Ich glaube, man braucht sich nicht mehr Gedanken zu machen
> als bei herkömmlichen Festplatten, eher im Gegenteil:
>
> Bei einer Festplatte kann sehr plötzlich ein Totalausfall
> auftreten, vor dem man auch durch SMART nicht rechtzeitig
> gewarnt wird (z.B. durch einen Headcrash mit Abrieb oder
> durch einen Motorschaden). Bei einer SSD ist das dagegen
> äußerst unwahrscheinlich, da es keine mechanischen Kompo-
> nenten gibt. Der PEC-Verschleiß der Zellen tritt allmäh-
> lich auf und lässt sich durch SMART abfragen, so dass man
> rechtzeitig für Ersatz sorgen kann.

Wenn es mal immer so wäre, aber statistisch gebe ich dir recht.
Ein Totalausfall ist bei einem SSD sehr selten.
Das man den Verschleiß abfragen kann halte ich hingegen für ein
Gerücht - die Bits kippen einfach irgendwann und das ist bei
defekten Zellen deutlich unterhalb von einigen Jahren.
Abfragen kann man nur wie viel bereits als defekt markiert
wurden - also nur die Defekte, die aufgefallen sind.
Hinzu kommt, dass genauso wie bei DRAM ionierierende Strahlung
zu Bitfehlern führen kann.
Hier stellt sich dann halt die Frage wie viele Bits die CRC
abfangen kann.

> Und dass man von wichtigen Daten regelmäßig Backups machen
> sollte, ist ja ohnehin klar, egal ob man SSDs verwendet
> oder nicht.
>
> > Möglicherweise sind die 4k längst nicht mehr aktuell, aber ich denke,
> > dass man mit 4k/32k noch sehr gut zurecht kommt, zumal das Filesystem
> > vorzugsweise in 32k Bereichen arbeitet.
>
> Ich habe es bei anderen Herstellern nicht nachgeschlagen,
> aber OCZ gibt für aktuelle SSDs 4 KB an.

Immerhin eine Aussage.

> > Viel wichtiger ist das korekte Alignment.
>
> Ja, auf jeden Fall.
>
> > Die DragonFly Empfehlung nicht alles zu Partitionieren sind bei kleinen
> > Medien mit wenig Reservere denoch nicht verkehrt.
>
> Die Empfehlung hat nichts mit der Reserve zu tun, sondern
> hat reine Performance-Gründe, um auszugleichen, dass kein
> TRIM verwendet wird. Auf die Lebensdauer dürfte es keinen
> nennenswerten Einfluss haben, da sich die gleiche Anzahl
> Schreibzugriffe auf die gleiche Anzahl Zellen verteilen.

Ja - auch wenn das in dem Abschnitt nicht deutlich geschrieben wurde.
Im Rest ist das ja auch erklärt.
 
> Matt Dillon hat übrigens mehrere MLC-SSDs von verschiedenen
> Herstellern "Burn-in-Tests" unterzogen, d.h. ununterbrochen
> mit der maximalen Geschwindigeit Daten draufgeschrieben,
> bis der erste Fehler zu Tage trat. In allen Fällen hielten
> die SSDs deutlich länger als der rein rechnerische Wert.
> Das lässt vermuten, dass die Hersteller-Angaben eher recht
> konservativ sind.

Fehler ist nicht gleich Fehler.
Ein defekter Block hat wenigstens ein Bit falsch, aber die CRC kann
einige fehlerhafte Bits kompensieren und es hängt vom Hersteller
des Mediums ab wie viele Bitfehler er pro Block zulässt, bis
dieser aus dem Verkehr gezogen wird.
Die Angaben der Chiphersteller beziehen sich übrigens auf Blöcke
in deren Sprache, die ja einige Pages beinhalten.
Man beschreibt einen Block mitunter mehrfach, bis alle Pages
geschrieben sind, aber das ist vom Verschleiss her egal, weil aus
physikalischer Sicht nur beim Wechsel von '1' auf '0' geschrieben
wird - die anderen Pages eines Blocks werden beim schreiben einer
einzigen Page nicht verändert und verschleissen daher nicht weiter.

-- 
B.Walter <bernd@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message