Re: FreeBSD auf SSD

On Mon, Jan 31, 2011 at 11:43:31PM +0100, Matthias Fechner wrote:
> On 31.01.11 18:29, 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.
>
> bei einer Intel SSD ist das nicht notwendig. Die 160GB Version hat
> intern 200GB und damit 40GB Reserve fest eingebaut.

Mal ein kleiner Technik-Exkurs.
Es hat sich seit den 64MB CF-Karten ja auch einiges verändert.

Das mit der "Reserve" muss man vorsichtig interpretieren.
NAND-Flash sind nicht fehlerfrei - einige Prozent von so einem Chip
sind schlicht defekt, d.h. von den 40G steht ohnehin nur noch ein
Bruchteil zur Verfügung und davon muss der Controller noch
Funktion von Gewinnen, die Rotation ist nämlich nicht nur zur
Verschleissveteilung, sondern auch für Performance zuständig und
da ist es ähnlich, wie bei Filesystemen Platz zu lassen, auch wenn
die technischen Details komplett andere sind.
Das Schreiben in Flash ist grundsätzlich erst mal langsamm.
Damit das schnell wird muss der auf Flash-Chips verteilen, was der
aber nur kann, wenn er auf allen Chips freien Platz hat.
Beim schreiben ist es leicht die Daten symetrisch zu verteilen, aber
frei wird nur das was die logischen Blöcke, die überschrieben werden,
gerade belegt hatten und da kann es statistisch schon mal ungünstiger
aussehen.
Im Fall vom ZFS Cache aber kein Problem, weil die Daten in der gleichen
Reihenfolge überschrieben werden, also auch symetrisch verteilt wieder
frei werden.
Ein halbwegs guter Controller fängt schon mal an in Idle-Zeiten
Blöcke umzukopieren, um den Rotationspool im Gleichgewicht zu halten.
Sowas wird gerne zusammen mit anderen Tätigkeiten als "Bookkeeping"
bezeichnet.

Was die Fehlerfreiheit angeht sind _alte_ NAND-Flash unterteilt.
Es gibt einen kleinen Bereich 100% fehlerfreie Blöcke mit einer hohen
Anzahl Schreibzyklen und einen großen Rest.
Im fehlerfreien Bereich werden im Regelfall die Verwaltungsdaten
abgeelegt, also welcher Block ist defekt, welcher physikalische Block
hat die Daten für welchen logischen Block, ...
Die Blöcke sind üblicherweise 264 statt 256, bzw. heutzutage ein 2^n
vielfaches davon, groß.
Das ist zum einen schon mal notwendig, um eine CRC reinzupacken, weil
man ja grundsätzlich erst mal nicht weiß wie lange so ein Block
funktioniert - zum anderen kann man aber bei den heutigen größeren
Blöcken auch einen Teil der Verwaltung mit darin unter bekommen.

Ein konkreter 4GB (32Gx8) SLC Chip (NAND32GW3F4A) hat übrigens eine
Pagegröße von 4224 Bytes.
Einen Großteil der überschüssigen 128 Bytes _muss_ man für CRC
nutzen, weil single-bit Fehler vorkommen können.
Unter Einbeziehung einer CRC gibt der Hersteller 100000 Schreibzyklen
an.
Ein Block laut Datenblatt hat 256kByte + Extra, aber im Rahmen von
Filesystemen ist die Pagesize das wichtige Kriterium, sofern an auf
Schreibperformance verzichtet.
Das mit der Schreibperformance erklrt sich dadurch, dass man immer
Blöcke schreibt, aber Pages löschen kann - wenn man mehr als eine
Page im gleichen Block schreibt dauert das genauso lange und das
bringt mehr Schreibbandbreite.
Bis zu 2% kann bereits ab Werk defekt sein, aber es wird im laufe der
Lebenszeit mehr.
Man kann Schreibzugriffe auf zwei Abschnitte verschachtelt ausführen,
d.h. man kann die Schreibgeschwindigkeit von beiden nutzen.
Ein Schreibvorgang dauert 500µs - mit Pages sind das 2x 8MB/s und
mit Blöcken 2x 512MB/s (ohne Chipinterleaving wohlgemerkt).
Die Schreibperformance ist ohne Page-erase, aber auch das machen
die Controller in Idle-Zeiten als Bookkeeping, sodass die Show
immerhin solange funktioniert, bis alle gelöschten Pages aufgebraucht
sind - auch das ist ein Grund warum man viele Blöcke im Pool haben
will.
Random-read ist 25µs.

Ein konkreter 2GB (16Gx8) MLC Chip (NAND16GW3D2B) hat eine größere
Pagegröße von 4320 Bytes, also mehr Platz für CRC - wohl aus gutem
Grund.
Ein Block hat hier 512KBytes + Extra - auch hier ist das ein
Performancevorteil mehrere Pages im gleichen Block auf einmal zu
schreiben.
Unter Einbeziehung einer CRC gibt der Hersteller 5000 Schreibzyklen
an - der Unterschied zu SLC dürfte deutlich sein.
Das heißt, dass die Resevere hier auch sehr schnell gebraucht werden
könnte.
Bis zu 2,5% kann bereits ab Werk defekt sein, aber es wird im laufe der
Lebenszeit mehr.
Auch hier gibt es keinen garantiert fehlerfreien Bereich mehr, außer
einem fehlerfreie Block 0 ab Werk.
Ein Schreibvorgang braucht 800µs und auch hier kann man zwei Bereiche
gleichzeitig nutzen.
Randomm-read ist 60µs.

Im Regelfall wird ein Hersteller in den Blöcken neben der CRC auch
die logische Blocknummer und einen Timestamp unterbringen, anhand
derer das Medium beim Booten weiß welche Page für den gleichen
logischen Block am aktuellsten ist.
Das erspart einem den bisher extra betrachteten Verwaltungsbereich
und bringt performance, liegt aber jetzt im Bereich der möglicherweise
nicht zuverlässig funktionierenden Flashzellen.

Wer meint wichtige Daten auf MLC zu speichern, sollte sich bei 5000
Schreibzyklen Gedanken machen.
Außerdem muss man sich vor Augen halten, dass zwar der kleinste
Wiederbeschreibbare logische Bereich 4k sind, aber größere Schreibtrans-
aktionen bis 256kB, bzw. 512kB schneller sein könnten.
Ich weiß nicht was der Markt sonst noch so an aktuelleren Chips hergibt.
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.
Viel wichtiger ist das korekte Alignment.
Die Chipgrößen sind übrigens echte GB.

Um noch mal auf 200GB für 160GB zurück zu kommen.
Von den 40GB sind (bei 2,5%) potentiel schon 5GB ab Werk defekt.
Also mit anderen Worten: Bis zu 12,5% der "Reserve" ist möglicherweise
im Auslieferungszustand schon nicht mehr vorhanden.
Und der Rest schmilzt wegen MLC auch mehr oder weniger schnell dahin.

Die DragonFly Empfehlung nicht alles zu Partitionieren sind bei kleinen
Medien mit wenig Reservere denoch nicht verkehrt.
Der größere Pool darf auch zu einem größeren Anteil kaput gehen.
Ein 4G Medium mit 3,8G nettokapazität muss bis zu 3,8GB funktionale
Blöcke aufbringen, um die auszufallen.
Das bis zu ist der spannende Punkt dabei, weil bei einer 2G Partitionierung
und den restlichen 1,8GB dem Medium als free bekannt braucht es auch
nur 2GB funktionale Blöcke aufbringen, weil die ungenutzten 1,8GB
auch keine physikalische Kapazität belegen.
Es kann gut sein, dass so ein Medium längst sein soll-netto nicht mehr
kann und dann plötzlich aussteigt, wenn man es eines Tages vollschreibt.

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