Trim @ Postville & Lucid 2.6.34

Seite 1 von 1 - Forum: Linux and other OS auf overclockers.at

URL: https://www.overclockers.at/linux/trim_postville_lucid_2_6_34_216912/page_1 - zur Vollversion wechseln!

Gräflicher schrieb am 14.06.2010 um 17:34

Hi,
hab die Postville noch mit der alten non-trim FW gekauft heute endlich mal ein Update auf die aktuelle Version gemacht.
Bei der Gelegenheit gleich Ubuntu auf Lucid aktualisiert und den 2.6.34 Kernel von http://kernel.ubuntu.com/~kernel-ppa/mainline/ installiert.
Soweit so gut.
Danach noch die Option 'discard' in die /etc/fstab eingetragen.

Resultat waren schlechtere Werte im Benchmark.

Hab mir also hdparm und das swiper.sh installiert. --> Input/Output Error.

Aha, da muss man mit dem swiper-intel.sh, also der für Postvilles gepatchten Version ran. Die läuft jetzt auch durch.

Nur: Wie kann ich feststellen, ob das Trim auch erfolgreich war? Ich vermute nämlich, dass nichts passiert ist.

swiper.sh gibt immer wieder "trimming 15035032 sectors from 6892 ranges" aus. Müsste das nicht weniger werden, weil ja bereits erfolgreich getrimmt wurde?

Benchmark hat sich auch nicht verändert.

Wie funktioniert das Trim vom 2.6.34 Kernel eigentlich genau? Reicht da wirklich die "discard"-Option? Sollte der dann munter drauflos trimmen und das swiper.sh ist ohnehin nicht mehr notwendig? Oder muss ich mit dem swiper.sh die Platte mal saubertrimmen und der Kernel kümmert sich das nichts mehr neues hinzukommt?

Vielleicht kann mir das jemand erklären? Wäre dankbar, im Netz hört man immer wieder widersprüchliches. Angefangen von "es reicht das discard einzutragen" bis "trim ist total verbuggt und hat nie richtig funktioniert".

Vielen Dank

Gräflicher schrieb am 15.06.2010 um 01:12

Ok, ich versuch mal die Fragen selber zu beantworten:

Reicht die "discard"-Option? Wie kann man es überprüfen?

Zitat
Ob wirklich alles funktioniert kann man testen indem man die belegten Sektoren einer Datei ermittelt mit
hdparm --fibmap filename
einen belegten Sektor liest zb. mit
hdparm --read-sector 66385920 /dev/sda
die Datei dann löscht und sync
rm filename;sync
und den Sektor nochmal liest.

In meinem Fall hat das funktioniert. Ist die Datei belegt hat der ausgelesene Sektor allerlei Zeug darin. Wird die Datei mit aktivem Trim gelöscht hat der Sektor nur mehr "0000 0000 ..."
Wird die Datei ohne Trim gelöscht bleiben ist der Sektor weiterhin mit Daten belegt.
Aktiviertes Trim (ext4) kostet ein wenig Leistung, die Platte geht vorerst langsamer als zuvor.

Wie kriegt man nun die ganzen Sektoren frei, die eigentlich noch zugemüllt sein müssten, weil man ja die ganze Zeit ohne Trim gearbeitet hat?
wiper.sh zweigt anscheinend keine Wirkung (zumindest auf meinem System). Der betroffene Sektor war zumindest auch nach wiper.sh nicht "sauber".

COLOSSUS schrieb am 15.06.2010 um 08:48

Wie rufst du wiper.sh denn auf? Das musst du naemlich schon im "scharfen" Modus machen - ´wiper.sh --commit [weitere Parameter]´, sonst kriegst du lediglich dry-runs, also eine Simulation des Vorgangs.

Gräflicher schrieb am 15.06.2010 um 09:23

Ja, klar.
die "normale" wiper.sh führt auf der Postville einen erfolgreichen Dry-Run aus, mit der --commit Option gibts aber den Input/Output-Fehler.

Daher auch die gepatchte wiper-intel.sh, welche die Range in 512er Blöcke aufteilt und daher auch kompatibel zu Intel SSDs ist.

sudo bash wiper-intel.sh --commit /dev/sda1

Läuft dann auch fehlerfrei durch, aber anscheinend ohne viel zu trimmen.

Funktioniert das Skript bei dir? Falls ja, könntest du die wiper.sh bitte anhängen?
Besten Dank