ingo2
Anmeldungsdatum: 15. Juni 2007
Beiträge: 2145
Wohnort: wo der gute Riesling wächst
|
Mein letzer Post hier in diesem Thread (wollte erst noch bis Januar warten): Die S3500 SSD ist sauschnell und 100% stabil ohne den kleinsten "Ruckler". Meine Probleme sind damit Vergangenheit, die 520 SSD war zu 99% die Ursache. Die tollen Speed-Angaben der 520 (Sandforce) sind eher "snake oil". Ich trage hier nochmal am 15.01.2013 mein endgültiges Urteil nach. Bye EDIT (14.01.2014): Hier der versprochene Nachtrag. Ich wähle diese Form, da ich einen neuen Post vermeiden möchte. An meinem Urteil ändert sich nichts. Die 520 SSD mit SF-2281 Controller war verantwortlich für die kleineren und auch mal handfeste "Freezes". Seit ich vor über 1 Monat (am 12.12.2013) nacheinander 2 andere SSD's eingebaut und getestet habe, läuft mein PC mit denen jetzt auch so zuverlässig, wie gewohnt! Die beiden getesteten SSD's hatten beide einen Intel-Controller:
Zuerst eine 320 SSD. Die hat schon über 1 Jahr im alten PC (ASUS M2N-E MoBo und SATA II) unter Squeeze brav ihren Diesnt getan und wurde nie getrimmt, da der Kernel 2.6.32 das noch nicht konnte. Die lief jetzt über 1 Woche absolut problemlos, auch am SATA III Port meines neuen Ivy-Bridge PC. Eine neue Intel S3500 SSD. Die läuft jetzt statt der 320 seit über 3 Wochen ebenfalls völlig problemlos. Habe sie mächtig gestresst mit "Trim" und ganze Partitionen samt Inhalt verschoben. Macht insgesamt 100GB geschriebene Daten. Hat inzwischen über 300 "power on hours".
Da alle 3 SSD's von Intel sind, schließe ich auf den Sandforce-Controller, welcher bei mir die Zicken gemacht hat. Ganz außen vor ist aber Intel dennoch nicht, eine SSD aus eigenem Haus sollte auch an einem hauseigenen Intel DH77EB MoBo am 1, SATA III Port des H77 PCH einwandfrei funktionieren. Fazit: 1. Eine SSD mit Sandforce-Controller kommt mir nicht mehr ins Haus. Und die 520 sieht nie wieder einen PC von innen. 2. Von Experimenten mit den neuen Hybrid Festplatten SSD+HD lasse ich komplett die Finger. 3. Falls Jemand findet, daß meine Erkenntnisse zur Option "-m" (minimum-free-extent) von fstrim und der Befehl e2freefrag fürs Wiki von Interesse sind, bitte nachtragen. Ich trimme jetzt die S3500 wöchentlich mit -m 1M. Das geht sehr schnell (2 -3 sec.) und erfaßt > 90% des freien Platzes.
|
ingo2
Anmeldungsdatum: 15. Juni 2007
Beiträge: 2145
Wohnort: wo der gute Riesling wächst
|
Hier noch eine Bestätigung meiner Überlegungen zu TRIM (fstrim -m). In diesem aktuellen Linux Driver Guide für professionelle SSD's wird auf S. 8 folgender Cron-Job empfohlen:
nice ionice -c idle fstrim -m 1M mount_point
wobei die Verwendung von 'ionice -c3' ein zusätzlicher sinnvoller Tipp ist. P.S.: die S3500 Intel SSD läuft und läuft und ... - keine Freezes mehr ☺
|
UbuntuFlo
Anmeldungsdatum: 8. Februar 2006
Beiträge: 12317
Wohnort: /home/flo
|
ingo2 schrieb: EDIT (14.01.2014):
Oh, lieber wieder ein neues Posting eröffnen. Habe erst durch Dein letztes Posting diesen Nachtrag gesehen 😬 1. Eine SSD mit Sandforce-Controller kommt mir nicht mehr ins Haus. Und die 520 sieht nie wieder einen PC von innen.
Kann ich so nicht bestätigen. Meine OCZ Vertex 2 rennt mit SF-C wie 'ne Eins.
3. Falls Jemand findet, daß meine Erkenntnisse zur Option "-m" (minimum-free-extent) von fstrim und der Befehl e2freefrag fürs Wiki von Interesse sind, bitte nachtragen.
Das ist interessant und ist im Wiki sicherlich gut aufgehoben… Müssten halt mal noch ein paar mehr testen und kommentieren. | flo@x201:~$ sudo fstrim -vm 1M /
/: 5542973440 bytes were trimmed
|
Geht deutlich schneller, jo. Habe das jetzt nicht mehr genau im Kopf: Der trimmt nur noch Dateien größer 1 M, oder was? ingo2 schrieb: wobei die Verwendung von 'ionice -c3' ein zusätzlicher sinnvoller Tipp ist.
Was genau macht dieser Zusatz? Liebe Grüße, Flo
|
ingo2
Anmeldungsdatum: 15. Juni 2007
Beiträge: 2145
Wohnort: wo der gute Riesling wächst
|
UbuntuFlo schrieb: ingo2 schrieb: EDIT (14.01.2014):
Oh, lieber wieder ein neues Posting eröffnen. Habe erst durch Dein letztes Posting diesen Nachtrag gesehen 😬
Das habe ich gemacht, weil ich einen Rüffel wegen meiner "Monologe" bekommen habe, ich aber andererseits eine endgültige Info versprochen hatte.
1. Eine SSD mit Sandforce-Controller kommt mir nicht mehr ins Haus. Und die 520 sieht nie wieder einen PC von innen.
Kann ich so nicht bestätigen. Meine OCZ Vertex 2 rennt mit SF-C wie 'ne Eins.
Da schau mal bei Alignment, da habe ich das im P.S. erwähnt. Die Freezes kamen vorzugsweise, wenn ich vorher in einem System auf einer "nicht 2MiB alignten" Partition gearbeitet hatte und dann auf sda1 gewechselt habe. Die 520 hat Intel 25nm Flash mit 2MiB erase block size.
3. Falls Jemand findet, daß meine Erkenntnisse zur Option "-m" (minimum-free-extent) von fstrim und der Befehl e2freefrag fürs Wiki von Interesse sind, bitte nachtragen.
Das ist interessant und ist im Wiki sicherlich gut aufgehoben… Müssten halt mal noch ein paar mehr testen und kommentieren. | flo@x201:~$ sudo fstrim -vm 1M /
/: 5542973440 bytes were trimmed
|
Geht deutlich schneller, jo. Habe das jetzt nicht mehr genau im Kopf: Der trimmt nur noch Dateien größer 1 M, oder was?
Nee, er meldet nur noch zusammenhängende und alignte freie Bereiche >= 1MiB an den Controller. Dafür habe ich die erase block size gesucht. Es wären bei mir sogar 2MiB optimal. das Kleinvieh macht dann die Müllabfuhr der SSD.
ingo2 schrieb: wobei die Verwendung von 'ionice -c3' ein zusätzlicher sinnvoller Tipp ist.
Was genau macht dieser Zusatz?
Disk I/O auf idle priority setzen, d.h. nur, wenn keine anderen Disk-Operationen anstehen.
Liebe Grüße, Flo
Viele Grüße, Ingo
|
UbuntuFlo
Anmeldungsdatum: 8. Februar 2006
Beiträge: 12317
Wohnort: /home/flo
|
ingo2 schrieb: Disk I/O auf idle priority setzen, d.h. nur, wenn keine anderen Disk-Operationen anstehen.
Ah, danke! Brauche ich jedoch nicht, da ich das immer nur händisch mache, wenn ich mal daran denke. Dann kommt ab und zu mal etwas mehr rum – wie gerade eben 😬 | flo@x201:~$ sudo fstrim -vm 1M /home/
/home/: 56817643520 bytes were trimmed
|
Liebe Grüße, Flo
|
ingo2
Anmeldungsdatum: 15. Juni 2007
Beiträge: 2145
Wohnort: wo der gute Riesling wächst
|
UbuntuFlo schrieb:
Dann kommt ab und zu mal etwas mehr rum – wie gerade eben 😬 | flo@x201:~$ sudo fstrim -vm 1M /home/
/home/: 56817643520 bytes were trimmed
|
Kommt immer das Gleiche rum. fstrim meldet immer alle aktuell freien Bereiche an die SSD (außer, du rufst es 2x ganz kurz hitereinbander auf).
Was nur wichtig ist, du solltest den Parameter -m nicht größer wählen as das alignment der Filesysteme, da laut Aussage der man page die Ermittlung "aligned" erfolgt. D.h. wenn du 8MiB angibst, meldet das Filesystem nur die freien Bereiche, die gleich oder größer als 8MiB sind und auch (bezüglich des Filesystems) 8MiB aligned sind. Der SSD werden nämlich nicht einzelne Sectoren/pages/.. gemeldet, sondern grundsätzlich Bereiche von ... bis. Je nach SSD können die Bereiche maximal 1 - 8 (oder 2 - 16?) GiB groß sein. Viele Grüße, Ingo
|
noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 28924
Wohnort: WW
|
Hallo, @UbuntuFlo: zu ionice steht auch was im Wiki ☺ Gruß, noisefloor
|
ingo2
Anmeldungsdatum: 15. Juni 2007
Beiträge: 2145
Wohnort: wo der gute Riesling wächst
|
Noch ein Hinweis zur Option '-m': vernünftigerweise sollte als "minimum free extent" mindestens der Wert einer NAND-page benutzt werden. Das ist die kleinste Einheit, die vom Flash gelesen werden kann, alles darunter beschäftigt nur unnötig den Controller. Bei aktuellen SSD's (25 und 20nm Chips) ist das 8K, in Zukunft dann 16K. Ohne die Option nutzt fstrim 4K, die kleinste Einheit im Dateisystem.
|
UbuntuFlo
Anmeldungsdatum: 8. Februar 2006
Beiträge: 12317
Wohnort: /home/flo
|
noisefloor schrieb: @UbuntuFlo: zu ionice steht auch was im Wiki
Thx! Gleich mal einlesen… Liebe Grüße, Flo
|
ingo2
Anmeldungsdatum: 15. Juni 2007
Beiträge: 2145
Wohnort: wo der gute Riesling wächst
|
UbuntuFlo schrieb: noisefloor schrieb: @UbuntuFlo: zu ionice steht auch was im Wiki
Thx! Gleich mal einlesen…
ein eifaches
man ionice
tut's auch - ist sehr gut erklärt dort 😉
Zumal man mit dem Begiff "ionice" den Wiki-Artikel nicht findet. Gruß, Ingo
|
chmatse
Anmeldungsdatum: 22. Februar 2014
Beiträge: Zähle...
|
Hallo zusammen Die "Batch discard" Variante ist zwar rasch eingerichtet, es hat mich aber gestört, dass ich dann - je nach Auslastung der Disk - doch wieder von einem crondir zum anderen wechseln muss (z.B. von monthly zu weekly). Sowas müsste meiner Meinung nach automatisiert werden. Daher habe ich mich mal rangesetzt und einen halb-intelligenten cronjob erzeugt, welcher je nach prozentualer Auslastung des Mountpoints sich selbst in ein anderes Verzeichnis verschiebt. Dadurch muss ich den cronjob nur einmalig manuell starten und ab dann geht alles von selbst (so die Theorie) 😬 Folgende Features habe ich dem Script verpasst: Distributionsunabhängiges Script (ich selber bin Gentoo User). Installiert sich, je nach Anzahl Mountpoints und deren Auslastung, ein oder mehrmals. Installiert (falls gewünscht) eine man page. Erkennt selbständig ob die Installation via /etc/cron.{monthly,weekly,daily,hourly} oder via /etc/cron.d (Auch dieses Verzeichnis wäre anpassbar) und crontab erfolgen muss. Die zu trimmenden Pfade können in einer Variabel im Script definiert werden. simpelste Handhabung. Einmaliges starten ohne option installiert den cronjob, einmaliges aufrufen mittels -d deinstalliert den cronjob (und eine allfällig installierte manpage). Prüft vor der Installation ob der verwendete Kernel, das eingesetzte Dateisystem und die Disk selber das TRIMMing überhaupt unterstützt.
Auf github habe ich eine kleine Webseite mit Instruktionen etc. eingerichtet. Vielleicht hat der eine oder andere von euch Lust das Script auch auf Ubuntu auszuprobieren und mir Feedback zu geben? Verschiedene Inputs aus diesem Thread und dem Wiki möchte ich noch in das Script einbauen.
Trim mit nice und ionice laufen lassen Optionsübergabe an fstrimm (z.B. "-m 1M") Unterstützung für encrypted partitions Logging
Ich hoffe ihr fasst das hier nicht als Werbeversuch auf. Ich habe vor zwei Wochen meine erste SSD erhalten und mich via eurem Wiki eingelesen. Da ich vom Wiki profitieren konnte wollte ich das in Form des "Hinweises" zu meinem Script wieder zurück geben. Lieber Gruss Matse
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7648
|
Uff. Und wozu ist das gut?
|
chmatse
Anmeldungsdatum: 22. Februar 2014
Beiträge: 4
|
frostschutz schrieb: Uff. Und wozu ist das gut?
Nunja... Primär wollte ich vermeiden, dass da z.B. in täglichen Intervallen getrimmt wird, wenn aufgrund der Anzahl leerer Blöcke auf der Disk ein trimmen einmal im Monat reichen würde (Jede Flashzelle hat ja auch nur eine begrenzte Anzahl Schreibzyklen übrig). Sekundär war es mir aber auch wichtig, dass ich da nicht immer wieder mal das script von /etc/cron.daily nach weekly etc. verschieben muss sondern dass es einmal installiert einfach alles selbst macht (fire and forget Prinzip). Wer also damit leben kann, dass seine SSD 29x zu viel innerhalb eines Monats getrimmt wurde und wen es nicht stört dass seine zu 88% ausgelastete Disk nur einmal in der Woche getrimmt wird (weil er vergessen hat von Weekly auf daily zu stellen), der braucht das script wohl nicht. Lieber Gruss Matse
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7648
|
chmatse schrieb: Jede Flashzelle hat ja auch nur eine begrenzte Anzahl Schreibzyklen übrig [...] Wer also damit leben kann, dass seine SSD 29x zu viel innerhalb eines Monats getrimmt wurde
Ich wusste bisher nicht, daß man zuviel trimmen kann - wenn die SSD ein TRIM-Befehl für einen bereits freien Block bekommt, sollte sich ja nichts ändern, und wenn man das discard-Flag des Dateisystems verwendet wird insgesamt eher mehr getrimmt als mit fstrim. Ich habe mein fstrim in cron.weekly, mir reicht das unabhängig vom Füllstand der SSD. Wer es in cron.hourly legt, würde mit dem discard-Flag des Dateisystems wohl besser dran sein, die Intention hier scheint ja zu sein möglichst alles getrimmt zu bekommen was kurzfristig frei wird, und das ist nun mal das was das discard-Flag macht. cron.daily oder cron.weekly (oder was dazwischen) ist Geschmackssache, cron.monthly sollte gegenüber cron.weekly wenig Vorteil bringen (wer fstrim einmal im Monat nicht bemerkt, der merkt es auch nicht einmal pro Woche...).
|
stfischr
Anmeldungsdatum: 1. März 2007
Beiträge: 19197
|
Das denke ich auch, zuviel trimmen kann man nicht. Ist halt nur nervig, wenn man häufig warten muss. Dann lieber discard.
|