Re: FreeBSD auf SSD

Bernd Walter wrote:
> Matthias Fechner wrote:
> > Oliver Fromme wrote:
> > > Das habe ich noch nicht ausprobiert, aber ich denke, dass
> > > die gleichen Empfehlungen gelten wie für eine Swap-Cache-
> > > Disk (*) unter DragonFly BSD: Die SSD so partitionieren,
> > > dass ein Teil unberührt bleibt (20% würde ich veranschla-
> > > gen), und die restlichen 80% als Device einbinden. Auf
> > > das Alignment sollte man dabei natürlich auch achten.

Wenn ZFS den Cache grundsätzlich immer linear von vorn bis
hinten schreibt, hast Du (Bernd) natürlich recht, d.h. man
braucht keinen unbenutzten Bereich zu lassen. Das gleiche
dürfte gelten, wenn man die SSD zur Beschleunigung von
gjournal(8) verwendet. Bei strikt sequentieller, gleich-
mäßiger Nutzung sollte so gut wie kein statisches Wear-
Leveling auftreten. Vorausgesetzt, Firmware und Controller
der SSD haben keinen Hirnschaden.

Die oben genannte Empfehlung, etwas Platz unberührt zu
lassen, gilt bei Random-Writes, also wenn ein normales
Dateisystem und/oder Swap zum Einsatz kommt.

> > 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).

Die Empfehlung, einen Teil einer jungfräulichen SSD unbe-
rührt zu lassen, hat einen ganz anderen Grund, nämlich um
die maximale Performance bei Random-Writes zu erhalten,
wenn das Betriebssystem kein TRIM verwendet. Anderenfalls
wird die SSD nämlich mit der Zeit immer langsamer; in
diesem Fall kann man die ursprüngliche Performance nur
durch »newfs -E« wieder herstellen, was natürlich alle
Daten löscht und daher eine Datensicherung erfordert.

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.

In meinem Fall habe ich das FreeBSD-Basissystem drauf,
src + ports + obj, /usr/local und einen Teil meines Homes.
Schreibaktivitäten summieren sich maximal auf ein paar
hundert MB pro Tag, und wenn ich mal das OS und/oder eine
größere Anzahl Ports aktualisiere (alle paar Monate mal),
können es vielleicht ein paar GB an einem Tag werden.
Damit überlebt die SSD mich selbst rein rechnerisch um
ein Vielfaches. OCZ gibt übrigens 3 Jahre Garantie.

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.

> 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.

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.

> 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.

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.

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd
"With sufficient thrust, pigs fly just fine.  However, this
is not necessarily a good idea.  It is hard to be sure where
they are going to land, and it could be dangerous sitting
under them as they fly overhead." -- RFC 1925
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message