ubuntuusers.de

praseodym schrieb:

Ausserdem hier unter Tuning kannst du die "swappiness"-Angaben ausprobieren.

Die bringen so gut wie gar nix. Ich habe das bei mir schon auf 0 (vorher 10) und nach spätestens 10 mal VM starten/stoppen (reboot eines Guest, Debian) ist Ende Gelände. Dann ist Reboot angesagt weil außer 100% Festplatte nix mehr geht. Absolut nachvollziehbar, sobald Swap genutzt wird, wird es unerträglich. Das Dilemma, ohne Swap kein vernünftiges Hibernate mehr. 👿

Frustriert schrieb:

Aber es ist mir immer noch absolut unverständlich, wie Brennprobleme (reproduzierbar gleich falscher MD5Sum Hash) mit einer Anwendung wie cdrecord/wodim mit der Speicherauslastung (real und virtuell in /swap)

@Frustriert, doch, gerade da. Weil Linux sich dann nur noch mit der Festplatte beschäftigt und nix anderes mehr durchgeht → Brennprobleme. 😉

Frustriert schrieb:

Sowas darf doch einfach nicht sein. Oder?

Nöö, sollte wirklich nicht sein. Ist aber leider so...

DeJe schrieb:

praseodym schrieb:

Ausserdem hier unter Tuning kannst du die "swappiness"-Angaben ausprobieren.

Die bringen so gut wie gar nix. Ich habe das bei mir schon auf 0 (vorher 10) und nach spätestens 10 mal VM starten/stoppen (reboot eines Guest, Debian) ist Ende Gelände. Dann ist Reboot angesagt weil außer 100% Festplatte nix mehr geht. Absolut nachvollziehbar, sobald Swap genutzt wird, wird es unerträglich. Das Dilemma, ohne Swap kein vernünftiges Hibernate mehr. 👿

Dann kann ich mir das laienhafte Rumspielen damit ja wohl schenken. Deine Beobachtungen scheinen auch zu Erklären, warum ich hier ebenfalls nach ca. 7-10 Tagen Opera (oder Firefox) neu starten muß, weil das ganze System dann einfach unheimlich zäh wird und buchstäblich minutenlang auf der Festplatte rumschruppt, was dann meist auch mit einer hohen Prozessorauslastung und Systemlast (laut gnome Systemmonitor) einhergeht.

Frustriert schrieb:

Aber es ist mir immer noch absolut unverständlich, wie Brennprobleme (reproduzierbar gleich falscher MD5Sum Hash) mit einer Anwendung wie cdrecord/wodim mit der Speicherauslastung (real und virtuell in /swap)

@Frustriert, doch, gerade da. Weil Linux sich dann nur noch mit der Festplatte beschäftigt und nix anderes mehr durchgeht → Brennprobleme. 😉

Und das Brennprogramm bekommt davon gar nix mit? Ist dabei dann der Datenfluß vom Brennprogramm zum Brenner unbemerkt gestört? Wie kommt es aber dann, daß die resultierenden kaputten CDs immer genau denselben, falschen md5sum-Wert bekommen? Sollte der dann nicht fúr jeden Brennvorgang derselben Vorlage unterschiedlich sein, das Ganze auf Zufälligkeiten basieren?

Frustriert schrieb:

Sowas darf doch einfach nicht sein. Oder?

Nöö, sollte wirklich nicht sein. Ist aber leider so...

Das läßt dann auch den Wechsel von zwei weitláufig Bekannten und hardcore Programmierer und only-Linux Die-Hards der ersten Stunde nach gut 10 Jahren zu BSD in einem neuen Licht erscheinen. Zuerst vor ca. 5 Jahren zu Dragonfly und seit kurzem zu FreeBSD. Beide sagten, Linux habe ein lausiges Speichermanagement, das über die Jahre immer wieder zu sporadischen und extrem seltsamen Fehlern und Effekten u.a. in einem CAD-Programm, aber auch mit Netzwerkfilesytemen und anderem führte und nie behoben werden konnte. Seit dem Umstieg auf BSD sind all diese seltsamen Probleme verschwunden. Das sollte mir als immer noch Linux-Neuling nach vielen zufriedenen OS/2-Jahren vielleicht auch zu denken geben.

Hast du das hier schon versucht? Hat bei mir alle Brennprobleme beseitigt:

http://forum.ubuntuusers.de/topic/kleines-projekt-mit-paketverwaltung-die-schil/

DeJe schrieb:

Absolut nachvollziehbar, sobald Swap genutzt wird, wird es unerträglich. Das Dilemma, ohne Swap kein vernünftiges Hibernate mehr. 👿

Wohin schreibt eigentlich 2.6.31-22-generic-tuxonice #73~ppa1-Ubuntu SMP bei einem "sudo pm-hibernate" seine Daten, in /swap oder in eine temp-Datei? TuxOnIce verweigert hier nämlich ebenfalls seinen Dienst, wenn ca. 1.5GB meiner 2.5GB /swap gefüllt sind bei 1GB max. möglichem RAM.

Frustriert schrieb:

Thorsten Reinbold schrieb:

Hast du das hier schon versucht? Hat bei mir alle Brennprobleme beseitigt:

http://forum.ubuntuusers.de/topic/kleines-projekt-mit-paketverwaltung-die-schil/

Von daher kommt ursprünglich mein obiger Beitrag 😉

Ich hatte ihn dort gepostet, da ich der Meinung war, daß meine Beobachtungen in direktem Zusammenhang mit den dort berichteten cdrkit/cdrtools/Brasero Problemen stehen, aber tomtomtom sah dies nicht so und verfrachtete meinen obigen Beitrag hierher.

DeJe schrieb:

praseodym schrieb:

Ausserdem hier unter Tuning kannst du die "swappiness"-Angaben ausprobieren.

Die bringen so gut wie gar nix. Ich habe das bei mir schon auf 0 (vorher 10) und nach spätestens 10 mal VM starten/stoppen (reboot eines Guest, Debian) ist Ende Gelände. Dann ist Reboot angesagt weil außer 100% Festplatte nix mehr geht.

Statt Neustart:

swapoff -a
swapon -a

primus pilus schrieb:

Statt Neustart:

swapoff -a
swapon -a

Werde ich mal probieren. Aber schon irgendwie einen Konsolenprompt zu bekommen dauert in solchen Fällen ewig. Da geht ein Reboot noch vergleichsweise schnell. 😉

Frustriert schrieb:

Ich sah mich hier mit einem sehr eigenartigen Effekt konfrontiert, der mein Vertrauen in in dir Qualität von Linux doch sehr erschüttert.

Mein älterer Laptop mit 1GB RAM in Vollbestückung läuft unter Mint8/Karmic 2.6.31-22-generic-tuxonice und hat eine 2.5GB Swap Partition. Opera mit einer Gazillion offener Tabs belegte nach ca 4 Tagen laut htop, wenn ich die Zahlen noch recht im Kopf habe, um die 1.5GB VIRT und 630MB RES. In SWAP waren ca 1.6GB benutzt.

Zu diesem Zeitpunkt konnte ich weder korrekt ein ISO Image auf CD-RW brennen, Brasero gab zwar vor zu arbeiten (löschen, Prüfsumme erstellen), aber praktisch ohne Laufwerksaktivitäten. Bei einem daraufhin erfolgten Brennversuchen mit cdrecord von der Befehlszeile aus, bekam ich 3 mal aufeinenderfolgend anschließend immer dieselbe falsche md5Summe zurück.

Zu diesem Zeitpunkt verweigerte auch Tuxonice einen sudo pm-hibernate, das Einzige, was hier halbwegs funktioniert.

Als ich daraufhin auf einen Verdacht hin Opera beendete und daraufhin wieder massiv Speicher frei wurde, produzierte cdrecord auf Anhieb eine korrekte CD-RW und anschließend funktionierte auch pm-hibernate.

...

Bist Du Dir sicher, daß Du wirklich cdrecord verwendet hast und nicht nur einen Symlink nach wodim?

Wodim ist ein toter Fork einer cdrecord Version vom September 2004.

Cdrecord hingegen wird ständig weiterentwickelt und da cdrecord mit root-Rechten läuft kann es auch eine höhere Priorität als andere Software (inclusive des Swappens falls das Betriebssystem es erlaubt) annehmen.

schily schrieb:

Frustriert schrieb:

Als ich daraufhin auf einen Verdacht hin Opera beendete und daraufhin wieder massiv Speicher frei wurde, produzierte cdrecord auf Anhieb eine korrekte CD-RW und anschließend funktionierte auch pm-hibernate.

...

Im Nachhinein erinnere ich mich dunkel an einenFall vor etwas mehr als einem Jahr, wo ich damals mit cdrkit/Brasero ebenfalls keine korrekte CD zustande bekam. Kurz nach einem transportbedingten (Schleppi) Neustart klappte es damals wundersamerweise aber dann plötzlich auch. Nur stellte ich damals keinen Zusammenhang mit der RAM/Swap-Auslastung her und sah die Schuld einfach bei dem überalterten cdrkit bzw. Brasero.

Bist Du Dir sicher, daß Du wirklich cdrecord verwendet hast und nicht nur einen Symlink nach wodim?

Ja, da zu diesem Zeitpunkt cdrkit schon durch Antiqua's Installationsscript und das letzte hier kompatible CDRecord 3.0 ersetzt war. Lediglich einen Systemneustart hatte ich bis zu dem Zeitpunk noch nicht vorgenommen. Aber der ist meines Wissens bei Linux in den meisten Fällen doch ohnehin nicht nötig, oder täusche ich mich da?

Wodim ist ein toter Fork einer cdrecord Version vom September 2004.

Ich weiß 😉 Aufgrund meiner langjährigen sehr guten Erfahrung mit dem OS/2-Port von cdrecord mag ich dein Original und verstand/verstehe den ganzen debianschen ideologischen Schwachsinn eh' nicht ganz. Warum lassen die Debianer dann nicht einfach dem Anwender die Wahl und bieten dein aktuelles CDRecord als aktuelles .deb Paket an, das einfach nachträglich den ganzen CDRKit-Kram komplett ersetzt?

Dann hätten die weiterhin ihre "klinisch reine" und unbefleckte Distribution und der Endanwender im Endeffekt trotzdem was er bevorzugt.

Frustriert schrieb:

schily schrieb:

Frustriert schrieb:

Als ich daraufhin auf einen Verdacht hin Opera beendete und daraufhin wieder massiv Speicher frei wurde, produzierte cdrecord auf Anhieb eine korrekte CD-RW und anschließend funktionierte auch pm-hibernate.

...

Im Nachhinein erinnere ich mich dunkel an einenFall vor etwas mehr als einem Jahr, wo ich damals mit cdrkit/Brasero ebenfalls keine korrekte CD zustande bekam. Kurz nach einem transportbedingten (Schleppi) Neustart klappte es damals wundersamerweise aber dann plötzlich auch. Nur stellte ich damals keinen Zusammenhang mit der RAM/Swap-Auslastung her und sah die Schuld einfach bei dem überalterten cdrkit bzw. Brasero.

Bist Du Dir sicher, daß Du wirklich cdrecord verwendet hast und nicht nur einen Symlink nach wodim?

Ja, da zu diesem Zeitpunkt cdrkit schon durch Antiqua's Installationsscript und das letzte hier kompatible CDRecord 3.0 ersetzt war.

Dann wäre zu klären ob das Problem in dem Verfälschen von Daten zu suchen ist oder im Zeitverhalten.

Wenn es das Zeitverhalten wäre, dann würde ich erwarten, daß es verschwindet wenn man beim Brennen driveropts=burnfree verwendet.

Ansonsten solltest Du das am Besten den Linux-Kernelentwicklern melden.

schily schrieb:

Dann wäre zu klären ob das Problem in dem Verfälschen von Daten zu suchen ist oder im Zeitverhalten.

Wenn es das Zeitverhalten wäre, dann würde ich erwarten, daß es verschwindet wenn man beim Brennen driveropts=burnfree verwendet.

Ich gehe stark vom Zeitverhalten aus. In diesem Fall dürfte auch eine hohe Priorität nicht helfen. Swap steht da über allen. 😉

Ob burnfree Abhilfe schafft, müßte man prüfen. Ich glaube es aber nicht. Das sind ja nicht nur kurze Ruckler sondern die Platte läuft mit 100% und verstopft mit dem swappen sämtliche Busse. Selbst der Wechsel in eine Konsole und Einloggen (ALT+STRG+F1) kann sich da über Minuten hinziehen.

DeJe schrieb:

schily schrieb:

Dann wäre zu klären ob das Problem in dem Verfälschen von Daten zu suchen ist oder im Zeitverhalten.

Wenn es das Zeitverhalten wäre, dann würde ich erwarten, daß es verschwindet wenn man beim Brennen driveropts=burnfree verwendet.

Ich gehe stark vom Zeitverhalten aus. In diesem Fall dürfte auch eine hohe Priorität nicht helfen. Swap steht da über allen. 😉

Unter Solaris kann ich cdrecord mit höherer Priorität als den Pager laufen lassen 😉 Pufferprobleme kann man damit aber auch nicht vollständig ausschließen, wenn etwas für cdrecord relevantes eingeswappt werden muß, es wird aber deutlich unwahrscheinlicher.

Was mir bei der ganzen Sache nicht so recht einleuchtet, ist, daß ich bei den fehlerhaften CD-RW's (hohe Speicher- und Swappartitions-Auslastung) immer exact dieselbe md5sum für /dev/cdrom0/ nach dem Brennen erhalte. Wenn es sich während des Brennens um irgendwelche zufälligen Busverstopfungen oder andere Störungen handeln sollte, müßte sich dann nicht auch der md5sum-Wert jedesmal entsprechend verändern?

Frustriert schrieb:

Was mir bei der ganzen Sache nicht so recht einleuchtet, ist, daß ich bei den fehlerhaften CD-RW's (hohe Speicher- und Swappartitions-Auslastung) immer exact dieselbe md5sum für /dev/cdrom0/ nach dem Brennen erhalte. Wenn es sich während des Brennens um irgendwelche zufälligen Busverstopfungen oder andere Störungen handeln sollte, müßte sich dann nicht auch der md5sum-Wert jedesmal entsprechend verändern?

Dann hast Du ein anderes Problem als wir glauben, aber mit den mir vorliegenden Infos kann ich Dir nicht weiterhelfen.

Ich glaube, wir sollten mal wieder zum Thema des Threads zurueckkommen:

Meine Erwartungen an Ubuntu wurden erfuellt. Es ist ein recht stabiles, anwenderfreundliches, kostenloses System.

Es ist aber schade, dass Ubuntu/Linux trotzdem immer weiter von seinem Ziel entfernt ist, eine ernstzunehmende (in Zahlen) Konkurrenz zu MS und Apple zu werden.

Es gab durchaus mal eine Zeit, wo das realistisch erschien, ich möchte nur "Vista" erwähnen. Mit Win 7 ist es vorbei.

Dazu kommt wohl noch das Google Betriebssystem als 3. System, das wars dann wohl.

Jetzt kann man natuerlich argumentieren, dass es gar keine Rolle spielt, wieviele Leute Linux benutzen, das muss ja nicht schlecht sein. (Thema Virus)

Aber ich behaupte mal, dass die Nicht-Akzeptanz von Linux durch die Massen auf viele Linuxer demotivierend wirkt. Nach meinem subjektivem Empfinden sind bereits Auflösungserscheinungen zu erkennen.

Sobald das mächtige Google sein Betriebssystem auf dem Markt positioniert hat, hat Mark S. eigentlich keinen Grund mehr, weiter Kohle in Ubuntu zu investieren.

Die Erwartungen an Ubuntu wurden erfuellt, die an Win 7 werden uebererfuellt. Daher habe ich eine Parallelinstallation, aber Ubuntu benutze ich nur noch selten.

Gruss, S.