Trim @ Postville & Lucid 2.6.34

Gräflicher

Here to stay

Registered: Dec 2001
Location: Baden bei Wien
Posts: 976

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

Here to stay

Registered: Dec 2001
Location: Baden bei Wien
Posts: 976

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

Administrator
GNUltra

Registered: Dec 2000
Location: ~
Posts: 12071

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

Here to stay

Registered: Dec 2001
Location: Baden bei Wien
Posts: 976

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

Gräflicher Here to stay Registered: Dec 2001 Location: Baden bei Wien Posts: 976	14.06.2010 - 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 Here to stay Registered: Dec 2001 Location: Baden bei Wien Posts: 976	15.06.2010 - 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 Administrator GNUltra Registered: Dec 2000 Location: ~ Posts: 12071	15.06.2010 - 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 Here to stay Registered: Dec 2001 Location: Baden bei Wien Posts: 976	15.06.2010 - 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

Trim @ Postville & Lucid 2.6.34

Forum Index > Software > Linux and other OS

Gräflicher

Gräflicher

COLOSSUS

Gräflicher