ubuntuusers.de

Wulfnoth schrieb:

Das Problem wurde in Ubuntu und Debian mit einem Update von acpi-support vor längerer Zeit behoben. Im Netzbetrieb wird seitdem automatisch 254 beim booten gewählt. Sieht man natürlich hinter usplash nicht, 😉 Mit deiner Platte hat das also nur bedingt was zu tun.

deswegen sagte ich ja auch ich habe es ohne den patch laufen lassen. habe bislang aber nur den netzmodus getestet. gut, mittlerweile ist auch der patch drauf.

gibts irgendeine sinnvolle lösung für das problem? wie handhabt das windows eigentlich?

DrScott schrieb:

Wulfnoth schrieb:

Das Problem wurde in Ubuntu und Debian mit einem Update von acpi-support vor längerer Zeit behoben. Im Netzbetrieb wird seitdem automatisch 254 beim booten gewählt.

Dann schick mal dein Laptop in den Supend und lasse in dann wieder aufwachen... 😉

Ich schick meinen Laptop nie in den suspend-mode. Wenn ich ihn brauch ist er an, wenn nicht ist er aus. Alles andere ist Energieverschwendung.

WOlMightyGreek schrieb:

gibts irgendeine sinnvolle lösung für das problem? wie handhabt das windows eigentlich?

Wenns unter Linux klackert, tuts das unter Windows auch. Nur dort schert das niemanden, entweder aus Gutgläubigkeit bei den Nutzern (Windows macht schon alles richtig) oder weil es eben Windoof ist. Die Lösung von Debian/Ubuntu ist momentan die sinnvollste. Wirklich ändern können nur die Festplattenhersteller was.

Wulfnoth schrieb:

Ich schick meinen Laptop nie in den suspend-mode. Wenn ich ihn brauch ist er an, wenn nicht ist er aus. Alles andere ist Energieverschwendung.

Es gibt auch "Suspend to Disk". Jedenfalls mein Laptop verbraucht dann ziemlich wenig Energie 😉 Es geht ja auch nicht darum, ob Du dies nun nutzt oder nicht. Es stimmt einfach nur nicht, dass der Gesamt-Bug mittlerweile richtig gefixt ist. Es fehlt eben noch etwas...

Wenns unter Linux klackert, tuts das unter Windows auch. Nur dort schert das niemanden, entweder aus Gutgläubigkeit bei den Nutzern (Windows macht schon alles richtig) oder weil es eben Windoof ist.

Also ganz so einfach scheint das meiner Meinung nach nicht zu sein. Auf meinem Laptop klackert Windows auch, das stimmt. Aber es klackert deutlich(!) seltener als "Linux"! Und das Klackern an sich, kann man auch nicht verhindern, es sei denn, man schaltet das Kopfparken komplett ab. Begründung folgt...

Die Lösung von Debian/Ubuntu ist momentan die sinnvollste. Wirklich ändern können nur die Festplattenhersteller was.

Ich vermute dagegen, dass eine richtige Lösung auch Änderungen an der Software erfordern. Es gab da mal eine Anleitung, wie man syslogd noch aggressiver Festplattenzugriffe verbieten konnte. Das hat damals bei mir wirklich etwas gebracht.

Ist doch klar: Sobald die Köpfe geparkt sind, dürfte eigentlich kein Schreibzugriff auf die Platte mehr erfolgen. Denn das holt die Köpfe ja sofort wieder zurück. Das bedeutet, dass man erstmal "Ruhezustand" definieren muss. In diesem Zustand darf dann nichts mehr (kurzfristig) auf Platte geschrieben werden. Die entsprechenden Daten müssen im Speicher vorgehalten werden und dann gebündelt von Zeit zu Zeit auf Platte gebannt werden. Da ist ein "Entparken" dann unvermeidbar. Genau aus diesem Grund kann man doch den schwarzen Peter nicht nur den Plattenherstellern zuschieben? Oder übersehe ich etwas?

DrScott schrieb:

Ist doch klar: Sobald die Köpfe geparkt sind, dürfte eigentlich kein Schreibzugriff auf die Platte mehr erfolgen. Denn das holt die Köpfe ja sofort wieder zurück. Das bedeutet, dass man erstmal "Ruhezustand" definieren muss. In diesem Zustand darf dann nichts mehr (kurzfristig) auf Platte geschrieben werden. Die entsprechenden Daten müssen im Speicher vorgehalten werden und dann gebündelt von Zeit zu Zeit auf Platte gebannt werden. Da ist ein "Entparken" dann unvermeidbar. Genau aus diesem Grund kann man doch den schwarzen Peter nicht nur den Plattenherstellern zuschieben? Oder übersehe ich etwas?

Sehe ich auch so. Die Festplattenhersteller schicken die Köpfe in die Parkposition und das BS greift zu oft auf die Platte zu. Wer macht nun das Falsche?

DrScott schrieb:

Ist doch klar: Sobald die Köpfe geparkt sind, dürfte eigentlich kein Schreibzugriff auf die Platte mehr erfolgen. Denn das holt die Köpfe ja sofort wieder zurück. Das bedeutet, dass man erstmal "Ruhezustand" definieren muss. In diesem Zustand darf dann nichts mehr (kurzfristig) auf Platte geschrieben werden. Die entsprechenden Daten müssen im Speicher vorgehalten werden und dann gebündelt von Zeit zu Zeit auf Platte gebannt werden. Da ist ein "Entparken" dann unvermeidbar. Genau aus diesem Grund kann man doch den schwarzen Peter nicht nur den Plattenherstellern zuschieben? Oder übersehe ich etwas?

Es ist aber schon die Frage ob die Festplattenhersteller die Festplatten nicht zu schnell in den Ruhemodus schicken. So wie ich das sehe geschieht dies ja praktisch jede Sekunde und das ist doch absolut Schwachsinnig. Sinnvoller wäre es die Festplatten erst nach einer gewissen Zeit ohne Zugriffe in diesen Modus zu versetzen. Natürlich wäre dann die logische Konsequenz, dass dies unter Linux nie geschehen würde.

DrScott schrieb:

Also ganz so einfach scheint das meiner Meinung nach nicht zu sein. Auf meinem Laptop klackert Windows auch, das stimmt. Aber es klackert deutlich(!) seltener als "Linux"! Und das Klackern an sich, kann man auch nicht verhindern, es sei denn, man schaltet das Kopfparken komplett ab. Begründung folgt...

Ich konnte unter Vista im direkten Vergleich zu Debian (vor dem Fix) keinen relevanten Unterschied beim Hochzählen feststellen.

DrScott schrieb:

Ich vermute dagegen, dass eine richtige Lösung auch Änderungen an der Software erfordern. Es gab da mal eine Anleitung, wie man syslogd noch aggressiver Festplattenzugriffe verbieten konnte. Das hat damals bei mir wirklich etwas gebracht.

Das mag richtig sein aber zumindest von den mir bekannten Linux-Distris ist die Debian/Ubuntu-Lösung die eleganteste. openSUSE hat das Problem noch nicht mal angegangen und Fedora meines Wissens nach auch nicht.

Die einfachste Lösung wäre folgende :

Man überlässt 100% dem Betriebssystem wann die Platte in den Ruhezustand zu schicken ist. Die Festplatte soll bzw. darf gar nichts mehr selbst entscheiden. Das Betriebssystem weiß nämlich immer noch am Besten wann es nichts zu tun hat.

glasen schrieb:

Die einfachste Lösung wäre folgende :

Man überlässt 100% dem Betriebssystem wann die Platte in den Ruhezustand zu schicken ist. Die Festplatte soll bzw. darf gar nichts mehr selbst entscheiden. Das Betriebssystem weiß nämlich immer noch am Besten wann es nichts zu tun hat.

Das wäre der richtige Ansatz, nur nutzt es bei den derzeit verbauten Platten nun nicht mehr viel.

glasen schrieb:

Die einfachste Lösung wäre folgende :

Das Betriebssystem weiß nämlich immer noch am Besten wann es nichts zu tun hat.

Das Problem ist ja, daß es nicht weiß, wann es wieder etwas zu tun haben wird.

Naja, die Festplatten wissen es noch weniger. Und bei Linux ist es eigentlich recht einfach. Der Sync auf die Festplatte wird normalerweise alle 5 Sekunden durchgeführt. Deshalb klackert bei vielen auch wenigstens alle 5 Sekunden die Festplatte. Verstärkt wird das dann noch durch das Logging, die Swap-Partition, usw.

Sorgt man also dafür das das Cache-Synchronisieren nur alle 15-30 Sekunden stattfindet, schaltet die Swap-Partition (Bei viel RAM eh unnötig) ganz ab und verlegt die Log-Dateien in eine RAM-Disk, welche erst beim Herunterfahren auf die Festplatte geschrieben wird oder schaltet es zum größten Teil oder ganz ab, dann wird schon deutlich weniger auf die Festplatte zugegriffen und die Festplatte kann öfters parken. Schaltet man jetzt noch zusätzlich den Laptop-Modus ein, dann kann die Festplatte komplett abschalten ohne alle 5-10 Sekunden wieder aus dem Schlaf gerissen zu werden.

Nun, was wäre denn eine sinnvolle Lösung? Die Ubuntuleute sollten daran arbeiten eine Art Notebook Edition herauszubringen oder eine Erweiterung, die es möglich macht mobile Hardware sinnvoll zu nutzen.

Es würde eigentlich schon reichen, wenn man Ubuntu von vorneherein so konfiguriert das die Festplattenzugriffe minimiert würden. Also nur so viele Log-Dateien wie notwendig, wenn möglich in einer RAM-Disk, usw. Davon würden alle Benutzer profitieren und nicht nur die Notebookbesitzer.

Also nur das konsequent umsetzen was in den diversen FAQs und Blogs schon geschrieben steht.

wenn das so sinnig ist, wieso macht man das nicht? ich hab z.b. keine ahnung wie ich das ändern kann ☺

Weil es nicht auf jedem Rechner sinnvoll ist. So kostet eine RAM-Disk, wie der Name schon sagt, RAM bzw. Hauptspeicher. Bei mehr als 1GB RAM spielen 16 oder 32MB MB weniger Hauptspeicher keine große Rolle, bei weniger als 1GB schon.

Die beste Lösung wäre wohl ein Paket anzubieten, welche die Maßnahmen bei Bedarf automatisch umsetzt, bzw. eine stufenweise Umsetzung anbietet. So könnte man die für den eigenen Rechner passenden Maßnahmen durchführen ohne ins Gefrickel zu verfallen.

Also, ich habe da zu dem Thema noch ne Frage: Bei ext4-Dateisystemen wird doch die Festplatte nicht mehr so oft beansprucht. Gilt dass dan auch für diesen "Bug" hier, dass er damit im Prinzip ein wenig umgangen wird? Oder hat das damit nix zu tun?

Und 2. Frage: Warum geht bei mir der Befehlt "scmartctl -a /dev/sdb" nicht? Er bringt immer "bash: command not found!"

EDIT: Meine Platte wird kaum beansprucht: Ich hab alles in den RAM geladen ☺

TDeveloper schrieb:

Also, ich habe da zu dem Thema noch ne Frage: Bei ext4-Dateisystemen wird doch die Festplatte nicht mehr so oft beansprucht. Gilt dass dann auch für diesen "Bug" hier, dass er damit im Prinzip ein wenig umgangen wird? Oder hat das damit nix zu tun?

Das sind zwei paar Schuhe.

Und 2. Frage: Warum geht bei mir der Befehlt "scmartctl -a /dev/sdb" nicht? Er bringt immer "bash: command not found!"

Weil du es Falsch geschrieben hast. Der Befehl lautet: smartctl -a /dev/sdb