[CentOS-de] SSD: Filesystem und TRIM unter CentOS 5.6?

[Tobias Crefeld]

Am Mon, 27 Jun 2011 15:48:11 +0200
schrieb Frank Thommen <frank.thommen at embl-heidelberg.de>:

> als Datendisk moechte ich in einer CentOS-Workstation (CentOS 5.6)
> eine SSD einbauen (Intel SSD 320 Serie, 120 GB).  Mir ist aber nicht
> ganz klar, welches Filesystem dafuer am besten geeignet ist und mir
> ist ueberhaupt nicht klar, wie die Sache mit TRIM oder anderen 
> Wartungskommandos funktionieren soll:
> 
> Ist ext4 das Filesystem der Wahl fuer SSDs oder ist ext3 genau so gut 
> geeignet oder ungeeignet?

Angeblich sollen nur in ext4fs und in btrfs Unterstützung für TRIM da
sein. btrfs wird AFAIK erst unter RHEL-6 und Derivaten unterstützt,
also nicht unter aktuellem CentOS-5.6. Offiziell unterstützt wird es
aber wohl auch bei RHEL erst ab nächstem Jahr werden.

btrfs hat den konzeptionellen Vorteil, dass es intern so arbeitet, wie
SSD es am liebsten mögen, nämlich mit "continuous snapshots". Es gibt
aber seitens Linux-Kernel bislang keine regulär-generelle Unterstützung
für SSD, weil die Realisierung von SSD nach wie vor zuviele
Hersteller-Spezifika aufweisen. Solange sich die Industrie da noch auf
nix geeinigt hat, ist man wohl für eine optimale Anbindung auf
proprietäre Lösungen bis hin zu filecards angewiesen.

> Muss ich TRIM oder irgendwelche anderen Wartungskommandos
> regelmaessig per Cronjob ausfuehren lassen oder erledigt das der
> Kernel automatisch fuer mich?

Bei ext4fs gibt es dafür einen Parameter. Ansonsten ist die Variante
"cronjob" wahrscheinlich suboptimal, aber die beste verfügbare Lösung.
Ansonsten ist es sicher eine gute Idee, die genutzte Plattenkapazität
gering zu halten.

Ein weiteres Problem stellt sich a.) bei diversen Host-Adaptern,
insbesondere bei SAS-Typen sowie b.) beim Wunsch, via LVM und/oder md
mehrere SSDs zu striped-volumes oder Soft-RAIDs zu bündeln. Bislang
habe ich jedenfalls zu b.) keine Aussage gefunden, dass hier ein TRIM
durchgereicht würde, zumal er ja auch sinnlos wäre, weil hier ein via
LV oder md eingebundenes filesystem ja eigentlich gar nicht wüsste,
wann die Teil-Devices (also die SSDs) ihr Trim brauchen könnten -
insbesondere, wenn auf denselben Devices weitere filesystems laufen,
die vielleicht grad gar keine Zusatzlast durch einen Trim brauchen
können.
Zu a.) gibt es wiederum häufig das Problem, dass sie selbst
Platten/SSD, die als einzelne Drives einem logischen/virtuellen
Laufwerk zugeordnet werden, nicht als SSD erkennen. Kann man gut dran
erkennen, wenn z.B. Funktionen aus der SMART-Familie keine weiteren
Erkenntnisse liefern. Bei reinen SATA-Host-Adaptern gibt es dieses
Problem seltener, aber dafür haben die meist auch nur wenige Ports und
Multiplexer a la SAS kennen die eh nicht.


Eine Alternative könnten derzeit RAID-Adapter von LSI oder Adaptec
sein, an die man neben einem Bündel von SAS/SATA-Platten auch noch
einige SSD-Platten anschließen kann. Dort wird dann in der Firmware
eingestellt, welches SSD-Platten sind und die werden dann als eine Art
Cache benutzt. Ist dann aber alles proprietär und wie gut es
funktioniert, weiß ich auch nicht.


BTW: Wenn Du eine gut funktionierende Lösung finden solltest, wie man mit Hilfe von SSD ein High-Performance-DBMS hinbekommt, das auch tablespace von 400 GB netto noch rasant verarbeiten kann, dann wäre ich für jeden Hinweis dankbar. 
Bislang habe ich nur das Angebot einer Appliance von Sun, aber die
fängt bei 1 TB an und ist auch ansonsten viel zu teuer.

-- 
Mit freundlichen Grüßen,
 Tobias Crefeld.

Tel: +49 - 89 - 2190 964-15, xmpp: crefeld at xabber.de

Cataneo GmbH
Lilienstrasse 8, D-81669 Muenchen
Tel: +49 (0) 89-2190 964-0, Fax: -48
Web: www.cataneo.de

Geschäftsführer: Michael Wölfle, Martin Gerull
HR: München HRB 144834


Phonetischer Auffahrunfall: http://bit.ly/bVtnsY