Triggeredupdates' Weblog

Just another WordPress.com weblog

Archiv für Januar 2009

Harddrive-Killer-Bug, die unendliche Geschichte?

Geschrieben von triggeredupdates - Januar 14, 2009

Mehr als zwei Jahre ist es her, da wurde auf Launchpad ein Bugreport mit dem Titel “High frequency of load/unload cycles on some hard disks may shorten lifetime” eingereicht, der als “Harddrive-Killer-Bug” bekannt wurde und für einiges an Aufregung und Verwirrung in der Community gesorgt hat.

Nach dieser langen Zeit scheint nun endlich ein brauchbarer Fix in die proposed-Quellen eingeflossen zu sein, der das Problem umgeht, allerdings auch neue Probleme mitbringt.

Was war passiert?
Zum Verringern des Strombedarfs und zum Schutz gegen Stöße werden die Schreibköpfe vor allem bei Notebookfestplatten bei Nichtgebrauch in eine Parkposition gefahren. Dieser Parkvorgang kann nur endliche Male ausgeführt werden, bei älteren Festplatten liegt die Anzahl bei 300.000, bei neueren 600.000 oder mehr. Wie oft das geschieht hängt zum Einen von den Einstellungen des Herstellers und zum Anderen davon ab, ob das Betriebssystem diese Einstellungen verändert. Im Regelfall lässt das Betriebssystem (ganz gleich ob Linux oder Windows) die Einstellungen wie sie sind, da man davon ausgeht, dass die Hersteller am besten wissen, wie oft ihre Festplatten diesen Parkmodus ausführen sollten. Aus welchen Gründen auch immer setzen viele Hersteller die Werte allerdings nicht sehr durchdacht sondern recht radikal und provozieren damit eine sehr hohe Anzahl von Parkvorgängen in kurzer Zeit, was einen schnellen Tod der Platte zur Folge haben kann. Aufmerksam wurde man auf das Problem durch wiederkehrende nervende Klick-Geräusche der Festplatte, die man beseitigen wollte.
Natürlich sollte man hier nicht in Panik geraten. Wirklich betroffen waren vor allem Heavy-User, die ihr Notebook rund um die Uhr laufen ließen, ohne damit zu arbeiten. Wer sein Notebook nur wenige Stunden am Tag an hat, der dürfte kaum von der verkürzten Lebensdauer der Festplatte gestört werden. Nur Zufall, dass gerade viele Linux-User Heavy-User sind ;)

Schnell kursierten diverse temporäre oder permanente Workarounds durchs Netz, die allesamt die ACPI-Einstellungen mittels hdparm änderten. Doch das reine Deaktivieren der Parkmodi war nicht wirklich eine Lösung. Während des Netzbetriebes mag dies eine brauchbare Lösung sein, im Akkubetrieb, in dem das Notebook also höchstwahrscheinlich in irgendeinerweise bewegt wird, könnte diese Einstellung mehr Schaden anrichten als verhindern. Die Debian-Entwickler patchten dann relativ schnell das Paket acpi-support, welches diverse ACPI-Einstellungen tätigt, was man allerdings aufgrund anderer Konfigurationen des Laptop-Modus und des Einsatzes bzw. der Umstellung auf pm-utils nicht ohne Weiteres in Ubuntu übernehmen konnte. Wahrscheinlich spielte auch die stärkere Erwärmung der Festplatte bei ausgeschaltetem APM bei der Entscheidung den Patch einzuspielen eine Rolle. Schließlich wurde das Workaround aus Debian etwas angepasst übernommen, doch funktionierte die Änderung nur bei den wenigsten, da zwar geprüft wurde, ob der Laptop-Modus die APM-Einstellungen der Festplatte übernimmt, aber nicht, ob dieser auch aktiv ist.

Kürzlich erschien nun eine neue Version (Danke an glasen für den Hinweis) von acpi-support in den proposed-Quellen von Intrepid und Hardy, die laut Changelog den Missstand endlich beheben soll. Und tatsächlich werden die angepassten Einstellungen beim Starten des Notebooks übernommen, leider zumindest unter Hardy noch nicht nach dem Aufwachen aus dem Standby. Dies liegt wiederum daran, dass pm-utils für die Kontrolle der Suspend-Modi zuständig ist. Hier muss man bisher noch selbst Hand anlegen.

Und nun?
Weiter oben schrieb ich von Problemen. Nun, ein Grund dafür, dass man die APM-Einstellungen nicht geändert hatte, war, wie erwähnt, dass man den Herstellern in dieser Hinsicht vertraut hat, zumal jedes Laufwerk unterschiedlich auf die neuen Einstellungen reagieren kann. So wurde berichtet, dass einige Laufwerke nach Setzen der neuen APM-Werte ziemlich heiß wurden, und womöglich dauerhaft Schaden hätten erleiden können.  Ich sehe nicht, inwiefern der Patch daran etwas ändert. Eine Gefahr sehe ich allerdings darin, dass der unbedarfte Anwender die neuen Einstellungen unbemerkt installiert bekommt, sollte das Paket in die update-Repos gelangen, und nicht wie bisher die Einstellungen selbst setzen musste. Hier sollte man also sehr vorsichtig sein.

Um fortgesetzt zu werden …

P.S. Wer nach dem Wiki-Artikel Notebook-Festplatten-Bug gearbeitet hat und das neue Paket testen will, sollte natürlich vorher die getätigten Einstellungen rückgängig machen.

Veröffentlicht in Linux, Ubuntu | Getaggt mit: , , | Kommentar schreiben »

Nvidia 180.22: Unfähig libglx.so zu öffnen

Geschrieben von triggeredupdates - Januar 9, 2009

Nach dem gestrigen Kernel-Update für Hardy habe ich mich dazu entschlossen auf den neuesten stabilen Nvidia-Treiber upzudaten, da ich sowieso das Modul neu bauen musste (ok mit dkms wäre mir das nicht passiert ;) , der Treiber einige neue Features mitbringt und insgesamt perfomanter sein soll.

Doch die Installation läuft anscheinend nicht immer reibungslos. Nach der Erstellung des Kernel-Moduls wird man von der Fehlermeldung aus dem Schlaf gerissen, der Installer könne die Datei libglx.so nicht finden. Trotzdem scheint die Installation erfolgreich abzuschließen und das Modul läd ohne Fehler, die Datei libglx.so und das Ziel libglx.so.180.22 sind an ihrem Platz – nur leider startet X dann im Low-Graphics-Modus.

Den Fehler lässt sich glücklicherweise recht leicht umgehen. Zuerst sollte man den Nvidia-Treiber wieder deinstallieren. Nun entpackt man das Installer-Archiv und kopiert die Datei libglx.so.180.22 in das entsprechende Verzeichnis:

$ sh NVIDIA*.run -x
$ sudo cp NVIDIA-Linux-x86_64-180.22-pkg2/usr/X11R6/lib/modules/extensions/libglx.so.180.22 /usr/lib/xorg/modules/extensions/

Damit der Installer zufrieden ist, muss man schließlich die Datei libglx.so auf libglx.so.180.22 zeigen lassen:

$ sudo ln -s /usr/lib/xorg/modules/extensions/libglx.so.180.22 /usr/lib/xorg/modules/extensions/libglx.so

Jetzt sollte die Installation ohne Probleme ablaufen und X wieder durchstarten.

Auf den ersten Blick konnte bei dem neuen Treiber keine wesentlichen Geschwindigkeitsverbesserungen feststellen, eher reichlich Probleme mit Compiz unter Hardy. Da für mich allerdings auch die 3D-Fähigkeiten von Metacity mehr als ausreichen, begnüge ich mich damit. Hier fällt mir auch schon eine Verbesserung auf: Das Scrollen im geöffneten Firefox-Fenster geht nun wesentlich runder von Statten, bisher war das mit aktiven Metacity-Effekten sehr unschön und CPU-lastig.

Mal sehen, was sich noch so im Alltagsbetrieb hervortut ;)

Veröffentlicht in Ubuntu | Getaggt mit: , , | Kommentar schreiben »

 
Follow

Bekomme jeden neuen Artikel in deinen Posteingang.