ssd und btrfs

[smutbert]

Hi,

demnächst werde ich zum ersten Mal Debian auf einer SSD installieren und das auch noch mit btrfs als Dateisystem. Das ist weiter auch gar kein Problem, aber ich frage mich was man bei SSDs beachten kann, soll oder muß und welche btrfs mount Optionen ratsam sind.

• ich werde möglichst viele Verzeichnisse als tmpfs einhängen, wie zB /tmp. Gerade bei letzterem wird das zwar eher kontrovers diskutiert, aber ich habe schon mit normalen Festplatten recht gute Erfahrungen damit gemacht.
• -o ssd
  Ist wohl nicht notwendig, weil es automatisch aktiviert wird, aber ich werde es dennoch in der fstab setzen.
• -o autodefrag
  Werde ich nicht wie gewohnt setzen, weil es bei SSDs nichts bringt, aber vermutlich für mehr Schreibzugriffe sorgt.

Darüber hinaus bin ich mir über einige Optionen im Unklaren…

• -o compress=lzo
  Normalerweise würde ich dazu tendieren Kompression zu verwenden, aber ich habe gelesen, dass einige (wenige?) SSDs die Daten sowieso komprimiert im Flashspeicher ablegen und dann wäre es zumindest unnotwendig die Daten vorher schon vom Dateisystem komprimieren zu lassen?
• -o discard
  Das bereitet mir am meisten Kopfzerbrechen. Der Beschreibung nach würde ich es sofort aktivieren, aber im Ubuntu Wiki http://wiki.ubuntuusers.de/Btrfs-Mounto ... ntoptionen wird sehr vehement davon abgeraten und anderswo liest man davon, dass es die Performance steigert oder beeinträchtigt oder gar die Chancen auf eine Dateisystemreperatur im Falle eines Crashs mindert.
  
  Also discard oder nicht discard, das ist hier die Frage?

Habe ich sonst noch etwas übersehen oder gibt es andere Dinge zu beachten?
Zur Information noch, mir geht es eher um Langlebigkeit als um Performance und falls es eine Rolle spielt. es geht um eine Samsung 840 Pro SSD mit 128GB.

vielen Dank,
lg smutbert

[charno]

Betreffend Kompression und SSDs: Einige SSDs (soweit ich verstanden habe primär die mit SandForce Controller) erreichen ihre hohe Geschwindigkeit unter Anderem durch das komprimieren auf SSD-Seite. Soweit ich das verstanden habe (ist schon ne weile her, dass ich mich mit SSDs beschäftigte) hilft das nicht, mehr "Platten"platz nutzen zu können, wohl aber auch der Langlebigkeit der SSD (durch weniger oft überschreiben derselben Stelle).
Bereits komprimierte Daten wirken für einen Komprimieralgorithmus mehr oder weniger wie zufällige Daten, und sind damit praktisch nicht komprimierbar. Damit entfällt auch der Vorteil der längeren Lebendigkeit und der Schreibgeschwindigkeit, allerdings hast du dafür den Vorteil mehr Daten auf weniger Speicherplatz zu bekommen.

Ich selbst setze Verschlüsselung (hat dieselben Effekte wie auf der CPU komprimieren) auf einem SandForce-Controller ein, und bin immer noch begeistert von der Geschwindigkeit.

[NAB]

Es wimmelt im Netz vor Ratschlägen, was man den armen kleinen empfindlichen und teuren SSDs alles nicht antun darf, damit sie auch bloß nicht übereilt Schaden nehmen. Das liest sich für mich so, als solle man die Dinger am besten in den Schrank legen und nicht mehr anfassen, damit ihnen auch ja nichts passiert.

Zum einen sind die Dinger inzwischen um einiges robuster geworden, zum anderen billiger ... das meiste kann man also ignorieren.

Wichtig ist das Alignment ... aber das hat nix mit dem Dateisystem zu tun.

Von "komprimierenden Controllern" würde ich ganz die Finger lassen ... zum einen steckt da meistens ein Sandforce-Controller drin, und die haben eine fatale Geschichte häufiger Fehlfunktionen hiner sich, zum anderen kann man die tollen Übertragungsgeschwindigkeiten nur erreichen, wenn man nichts als reine Textdateien auf der Platte hat und zum dritten gibt es genug kostengünstige Angebote ohne diese "Mogelcontroller".

Und dann macht auch "-o compress=lzo" Sinn, wenn du die Geschwindigkeitseinbuße/CPU-Last in Kauf nehmen magst.

Was das Discard angeht, würde ich zum "Batched Discard" raten ... entweder täglich oder wöchentlich:
http://wiki.ubuntuusers.de/SSD/TRIM
Das ist kontrollierbarer, als wenn das Dateisystem "irgendwann irgendwas" macht.

Und die Mountoption "noatime" macht Sinn ... solange du die "atime" nicht für irgendwas brauchst.
https://btrfs.wiki.kernel.org/index.php ... erformance

Samsung 840 Pro SSD mit 128GB.

Gute Wahl! Die Platte komprimiert nicht, also könntest du die Kompression einschalten.
Und die Pro-Variante hat keine Reserveblöcke, du solltest also nur ca. 120 GB partitionieren.

[catdog2]

Von "komprimierenden Controllern" würde ich ganz die Finger lassen ... zum einen steckt da meistens ein Sandforce-Controller drin, und die haben eine fatale Geschichte häufiger Fehlfunktionen hiner sich, zum anderen kann man die tollen Übertragungsgeschwindigkeiten nur erreichen, wenn man nichts als reine Textdateien auf der Platte hat und zum dritten gibt es genug kostengünstige Angebote ohne diese "Mogelcontroller".

Das liegt aber nicht nur am Controller selbst oder der Firmware. Die Teile werden aufgrund von gewissen Features gerne bei billigeren SSDs eingesetzt um minderwertige Flash Chips "aufzuhübschen". Die Kompression ist eine Sache um hohe Geschwindigkeit zu simulieren und Schreibzugriffe zu sparen. Ein besonders fieses Feature ist, dass die Dinger so Konfiguriert werden können, dass sie mit der Zeit (Je nach Schreibzugriffen) immer langsamer werden um mit höherer Wahrscheinlichkeit das Garantieende zu erleben man aber trotzdem mit guten Werten Werben kann.

Zur Information noch, mir geht es eher um Langlebigkeit als um Performance und falls es eine Rolle spielt. es geht um eine Samsung 840 Pro SSD mit 128GB.

Samsung hat einen guten Ruf in Sachen SSD.
Allgemein würde ich mir nicht allzuviele Sorgen machen. Um heutige SSDs (ausser vllt die ganz Billigen) ernsthaft totzuschreiben musst du die täglich mehrmals vollständig vollschreiben. Das letzte bisschen Schreibzugriff wegzuoptimieren ist den Aufwand also nicht Wert.
Und wie NAB schon gesagt hat, umso mehr Reserveblöcke du abzwacken kannst umso weniger problematisch wird das nochmal.

Es wimmelt im Netz vor Ratschlägen, was man den armen kleinen empfindlichen und teuren SSDs alles nicht antun darf, damit sie auch bloß nicht übereilt Schaden nehmen. Das liest sich für mich so, als solle man die Dinger am besten in den Schrank legen und nicht mehr anfassen, damit ihnen auch ja nichts passiert.

Vor 10 Jahren vielleicht…

//edit:

Wichtig ist das Alignment ... aber das hat nix mit dem Dateisystem zu tun.

Wenn du nicht vor hast ein altes Debian zu installieren sollte der Installer das eh gleich richtig machen.

//edit2:

Und die Mountoption "noatime" macht Sinn ... solange du die "atime" nicht für irgendwas brauchst.

relatime dürfte aber ein guter Kompromiss sein, wenn man sich nicht sicher ist ob man wirklich drauf verzichten kann.

//edit3:
Hier mal ein paar Daten: http://www.anandtech.com/show/6459/sams ... f-tlc-nand
Sehr konservativ gerechnet kannst du also wenn man dem glaubt täglich 30GB schreiben, 10+ Jahre lang. (Die Pro hat MLC)

[NAB]

Und die Mountoption "noatime" macht Sinn ... solange du die "atime" nicht für irgendwas brauchst.

relatime dürfte aber ein guter Kompromiss sein, wenn man sich nicht sicher ist ob man wirklich drauf verzichten kann.

Das sollte eh default sein, siehe Link oben.

[smutbert]

- relatime ist default. Dabei werde ich es belassen, auch wenn ich atime wahrscheinlich nie vermisse…
- und offensichtlich legt die Samsung SSD die Daten nicht komprimiert ab - gut zu wissen

[…]

Samsung 840 Pro SSD mit 128GB.

Gute Wahl! Die Platte komprimiert nicht, also könntest du die Kompression einschalten.
Und die Pro-Variante hat keine Reserveblöcke, du solltest also nur ca. 120 GB partitionieren.

Danke für den Hinweis, das war mir neu!
Jetzt wo ich danach gesucht habe, habe ich auch gefunden, dass man dieses Overprovisioning aktivieren kann - natürlich nur mit einem Windows Programm (Magician SSD management utility). Ich bin mit nicht sicher ob ich deswegen Windows installieren soll, aber immerhin könnte ich dann auch gleich überprüfen, ob die Firmware aktuell ist.

Weiß hier zufällig jemand, ob das Magician SSD management utility beim Aktivieren von Overprovisioning mehr oder etwas anderes macht als einfach nur eine leere Partition zu erzeugen?
Auf diese Frage habe ich trotz intensiven Googlens keine richtige Antwort gefunden.

[catdog2]

Wenn Samsung da keine eigenen komischen Dinge dreht: http://www.thomas-krenn.com/en/wiki/SSD ... ing_hdparm

Meines Wissens sollte es aber auch reichen am Ende einfach einen Bereich unpartitioniert zu lassen.

[NAB]

Jetzt wo ich danach gesucht habe, habe ich auch gefunden, dass man dieses Overprovisioning aktivieren kann - natürlich nur mit einem Windows Programm (Magician SSD management utility).

Ich hab nur Erfahrung mit den Samsung 830ern, und da war SSD Magician eine rechte Enttäuschung. Viele bunte Schaltflächen und wenig Funktionalität.

Meines Wissens wird auf der 840er auch nur ein unpartitionierter Speicherbereich erzeugt ... das kannst du auch unter Linux erreichen. Wichtig ist ja nur, dass die SSD weiß, dass dieser Speicher unbenutzt ist, somit also für Wear-Leveling zur Verfügung steht.
http://extreme.pcgameshardware.de/ssd-h ... oning.html

Interessant und umfassend zu dem Thema:
http://en.wikipedia.org/wiki/Write_amplification

aber immerhin könnte ich dann auch gleich überprüfen, ob die Firmware aktuell ist.

Die momentane Firmware sollte dir auch hdparm anzeigen, und aktualisieren kannst du sie mit den ISO-Images für den Mac:
http://www.samsung.com/global/business/ ... loads.html
Oder mit etwas gepfrickel auch mit einem USB-Stick:
http://www.content-space.de/dokuwiki/bl ... with_linux

Samsung bringt übrigens recht selten Firmware-Updates raus, was nach meiner Erfahrung ein gutes Zeichen ist, dass sie die Sache im Griff haben.

[smutbert]

Alles klar, danke noch einmal.

[BeWo]

Hallo zusammen

Da hätte ich auch noch eine Frage bezüglich SSDs.

Bei Debian 8 beabsichtige ich, btrfs als Dateisystem zu verwenden.
In meinem Computer ist eine SSD.
Aktuell verwende ich bei Debian 7 das Batched Discard für den Trim der SSD.
Das wird im Cron-Job 1x täglich ausgeführt.

Meine Frage ist:
Wird das Batched Discard für Debian 8 noch benötigt?
Oder erkennen moderne Dateisysteme inzwischen selber, ob eine SSD verwendet wird?

Vielen Dank für Eure Unterstützung

Bernhard

[peschmae]

Bereits komprimierte Daten wirken für einen Komprimieralgorithmus mehr oder weniger wie zufällige Daten, und sind damit praktisch nicht komprimierbar. Damit entfällt auch der Vorteil der längeren Lebendigkeit und der Schreibgeschwindigkeit, allerdings hast du dafür den Vorteil mehr Daten auf weniger Speicherplatz zu bekommen.

Naja, du komprimierst ja vorher selber und das sehr schnell; zudem kommen weniger Daten bei der SSD an. Von dem her hast du die beiden Vorteil natürlich trotzdem. Vorausgesetzt deine CPU kann so schnell komprimieren, aber die da eingesetzten Algorithmen sind typischerweise sehr schnell. Zusätzlich hast du noch den Vorteil dass du tatsächlich mehr Nutzdaten unterbringen kannst, als wenn die interne SSD-Logik das vor dir versteckt.
(Ausser natürlich die SSD Lügt und hat in Wahrheit weniger Speicherplatz als sie vorgibt, weil sie von einer guten Kompressionsrate ausgeht, aber von sowas habe ich noch nicht gehört)

MfG Peschmä

[smutbert]

@BeWo

Es hat sich nichts geändert — man hat nach wie vor die Wahl zwischen dem manuellen Ausführen von fstrim oder dem automatischen Discard/Trim. Zumindest bei BTRFS bleibt die automatische Variante standardmäßig deaktiviert, obwohl BTRFS durchaus erkennt, ob es auf einer SSD liegt oder nicht und dementsprechend sein Verhalten etwas anpaßt.
Ich glaube discard bleibt hauptsächlich deswegen standardmäßig deaktiviert, weil die frei gewordenen Speicherbereiche im Falle eines Fehlers bei der Wiederherstellung helfen könnten.

Aktivieren kann man discard mit der gleich lautenden Mountoption „discard“. Ich habe das jetzt seit ~1 Woche in der fstab drin. Bis jetzt sind wie erwartet keinerlei Probleme aufgetaucht…

[wanne]

Damit entfällt auch der Vorteil der längeren Lebendigkeit und der Schreibgeschwindigkeit,

Die Langlebigkeit bleibt erhalten. Ob das ding jetzt weniger schreibt, weil es komprimiert, oder weil das Dateisystem Komprimiert, ist wurst. Auch die schreibgeschwindigkeit ist ja nicht das Ziel, sondern dass die Gewünschten daten möglichst schnell auf der HD landen. Und die sind nach der kompression dann weg.

[catdog2]

Die Kompression dürfte in den meisten Fällen eher von Vorteil sein sei es um Platz zu sparen oder um der Performance willen (wo das meines Wissens selten negativ durchschlägt weil die CPUs einfach schnell genug sind).
Btrfs versucht auch nur zu komprimieren, wenn es was bringt:

What happens to incompressible files?

There is a simple decision logic: if the first portion of data being compressed is not smaller than the original, the compression of the file is disabled -- unless the filesystem is mounted with compress-force. In that case it'll be compressed always regardless of the compressibility of the file. This is not optimal and subject to optimizations and further development.

Auch kann man das zumindest theoretisch auch für einzelne Dateien/Verzeichnisse steuern, leider beschränkt sich das wegen fehlendem tooling im Moment auf das setzen des compression flags (chattr +c).

Naja bleibt zu hoffen, dass Btrfs mal in einen produktiv einsetzbaren Zustand kommt. Baustellen und Probleme haben zwar abgenommen aber gibt immer noch genügend.