Mein Problem ist, dass eine DVD-RW fehlerhaft gebrannt wurde, weil vermutlich zuviel swap vorhanden war und das das Lesen der Brennquelle ausgebremst hat. Ein swapoff -a mit folgendem swapon -a bringt nichts. Ohne swap brennen und gleichzeitig andere Dinge tun, ist auch so eine Sache, zumindest wenn das RAM unter 256MB liegt und X aktiv benutzt wird. Wie versetze ich die swap-Partition in einen Zustand wie nach einem Neustart? Al
Al Bogner wrote: [Sunday 28 December 2003 18:13]
Mein Problem ist, dass eine DVD-RW fehlerhaft gebrannt wurde, weil vermutlich zuviel swap vorhanden war und das das Lesen der Brennquelle ausgebremst hat.
Das ist aber eine verwegene Theorie.
Ein swapoff -a mit folgendem swapon -a bringt nichts.
Vermutlich, weil es eben nicht am swap liegt.
Ohne swap brennen und gleichzeitig andere Dinge tun, ist auch so eine Sache, zumindest wenn das RAM unter 256MB liegt und X aktiv benutzt wird.
Wieso brennst du nicht einfach langsamer, wenn dein System nicht mitkommt? Vielleicht bringt es auch etwas, den FIFO-Buffer von cdrecord größer zu machen - der ist standardmäßig auf 4 MB, wenn ich meiner SuSE8.2 manpage trauen darf. Das ist reichlich wenig bei hohen Geschwindigkeiten.
Wie versetze ich die swap-Partition in einen Zustand wie nach einem Neustart?
swapoff / swapon wäre dazu sicherlich ausreichend. Thomas.
Am Sonntag, 28. Dezember 2003 18:34 schrieb Thomas Hofer:
Al Bogner wrote: [Sunday 28 December 2003 18:13]
Mein Problem ist, dass eine DVD-RW fehlerhaft gebrannt wurde, weil vermutlich zuviel swap vorhanden war und das das Lesen der Brennquelle ausgebremst hat.
Das ist aber eine verwegene Theorie.
Warum? Normalerweise funktioniert das Brennen in jeder Geschwindigkeit problemlos. Ich merke das auch sonst nach vielen rsync, find, etc., dass der swap-Bereich drastisch steigt und dann Programme aus dem swap relativ langsam geladen werden. Nach einem Neustart gibt es beispielsweise nicht die geringsten Probleme.
Ein swapoff -a mit folgendem swapon -a bringt nichts.
Vermutlich, weil es eben nicht am swap liegt.
Das meinte ich anders, nämlich nicht auf das Brennen bezogen. Ich wollte damit erreichen, dass top danach keinen swap mehr anzeigt. 512MB RAM sollten eigentlich genug sein.
Ohne swap brennen und gleichzeitig andere Dinge tun, ist auch so eine Sache, zumindest wenn das RAM unter 256MB liegt und X aktiv benutzt wird.
Wieso brennst du nicht einfach langsamer, wenn dein System nicht mitkommt?
Wie gesagt, normalerweise kommt das System locker mit. Nur nachdem ein Script mit diversen Rechnern diverse Partitionen synchronisiert hat, gibt es Probleme.
Vielleicht bringt es auch etwas, den FIFO-Buffer von cdrecord größer zu machen - der ist standardmäßig auf 4 MB, wenn ich meiner SuSE8.2 manpage trauen darf. Das ist reichlich wenig bei hohen Geschwindigkeiten.
Guter Hinweis, ich dachte mir, dass das eventuell bei onthefly nichts bringt. So wird gebrannt. In diesem Fall "onthefly" if [ "$ONTHEFLY" = "j" ]; then sectors=$("$MKISOFSVERSION" -quiet -f -allow-lowercase -r -l -hide-rr-moved -V $1 -graft-points -path-list "$GRAFTPOINTSLIST" -print-size 2>/dev/null) "$MKISOFSVERSION" -quiet -f -allow-lowercase -r -l -hide-rr-moved -V $1 -graft-points -path-list "$GRAFTPOINTSLIST" 2>/dev/null | $CDRECORDVERSION dev=$DEVICEPAR -v driveropts=burnfree -dao -overburn speed=$XFACH -pad -data -tsize=${sectors}s - else if [ "$MEDIUMKAT" = "CD" ]; then $CDRECORDVERSION dev=$DEVICEPAR -v driveropts=burnfree -pad -dao -overburn speed=$XFACH fs=32m -data "$BRENNDATEI" else #DVD $CDRECORDVERSION dev=$DEVICEPAR -v driveropts=burnfree -dao -overburn speed=$XFACH fs=32m -data "$BRENNDATEI"* fi fi
Wie versetze ich die swap-Partition in einen Zustand wie nach einem Neustart?
swapoff / swapon wäre dazu sicherlich ausreichend.
Ich muß das mal in Verbindung mit dem Script vor dem Brennen probieren. Da das aber 2-3h + Brennezeit dauert, darf das der Rechner alleine in der Nacht machen. Al
Al Bogner wrote: [Sunday 28 December 2003 18:48]
Am Sonntag, 28. Dezember 2003 18:34 schrieb Thomas Hofer:
Al Bogner wrote: [Sunday 28 December 2003 18:13]
Mein Problem ist, dass eine DVD-RW fehlerhaft gebrannt wurde, weil vermutlich zuviel swap vorhanden war und das das Lesen der Brennquelle ausgebremst hat.
Das ist aber eine verwegene Theorie.
Warum? Normalerweise funktioniert das Brennen in jeder Geschwindigkeit problemlos. Ich merke das auch sonst nach vielen rsync, find, etc., dass der swap-Bereich drastisch steigt und dann Programme aus dem swap relativ langsam geladen werden. Nach einem Neustart gibt es beispielsweise nicht die geringsten Probleme.
Ich habe dich mißverstanden - ich dachte, du meinst, daß das bloße Vorhandensein einer Swap-Partition ein Problem ist. Wenn nach I/O intensiven Vorgängen alle inaktiven Prozesse ausgeswapt wurden, dann kann das später natürlich zu Verzögerungen beim Aktivieren dieser Prozesse führen. Die Seek-Aktivität kann dann bei den hohen Zugriffszeiten von IDE-Platten vermutlich auch den Brennprozeß in die Knie zwingen. Ein großer FIFO kann da meines Erachtens viel helfen.
Vielleicht bringt es auch etwas, den FIFO-Buffer von cdrecord größer zu machen - der ist standardmäßig auf 4 MB, wenn ich meiner SuSE8.2 manpage trauen darf. Das ist reichlich wenig bei hohen Geschwindigkeiten.
Guter Hinweis, ich dachte mir, dass das eventuell bei onthefly nichts bringt.
Laut der manpage gibt es den FIFO vor allem für Pipes von mkisofs in cdrecord. Da gibt es auch einige Hinweise für die Dimensionierung. Thomas.
Am Sonntag, 28. Dezember 2003 19:35 schrieb Thomas Hofer:
Laut der manpage gibt es den FIFO vor allem für Pipes von mkisofs in cdrecord. Da gibt es auch einige Hinweise für die Dimensionierung.
Die Manpage verstehe ich nicht:
It is not wise to use too much space for the fifo. If you need more than
8 MB to write a CD on an idle machine, your machine is either
underpowered, has hardware problems or is mis-configured.
Also mein Rechner war garantiert "idle", als ich schlief :-)
Nur fürs Brennen würde ich einen Celeron 1300 mit 512MB RAM und 80GB HD
nicht als "underpowered" betrachten, wenn es auch sicher schnellere
Rechner gibt.
Meine Erfahrungen bei anderen langsameren Rechnern mit alten HDs zeigte,
dass fs=32m sich am besten auf die Brenngeschwindigkeit auswirkte. Ich
testete damals Audio-CDs. Ich will ja nicht 100% ausschließen, dass da
etwas miskonfiguriert war, ich kann es mir aber nicht vorstellen und so
wie ich Jörg einschätze, würde er meinen, dass SuSE eine einzige
Miskonfiguration ist. Augenblicklich regt er sich ja ziemlich über
Linux auf und meint sinngemäß, dass Linus keine Ahnung von
Programmieren hat, zB MID
Al Bogner wrote: [Sunday 28 December 2003 19:58]
Am Sonntag, 28. Dezember 2003 19:35 schrieb Thomas Hofer:
Laut der manpage gibt es den FIFO vor allem für Pipes von mkisofs in cdrecord. Da gibt es auch einige Hinweise für die Dimensionierung.
Die Manpage verstehe ich nicht: It is not wise to use too much space for the fifo. If you need more than 8 MB to write a CD on an idle machine, your machine is either underpowered, has hardware problems or is mis-configured.
Also mein Rechner war garantiert "idle", als ich schlief :-) Nur fürs Brennen würde ich einen Celeron 1300 mit 512MB RAM und 80GB HD nicht als "underpowered" betrachten, wenn es auch sicher schnellere Rechner gibt.
Der CD-Writer hängt hoffentlich auch einem anderen Kabel als die Festplatte? Mit welcher Geschwindigkeit schreibst du eigentlich? 32 fach wären z.B. 4,8 MB pro Sekunde - das hört sich zwar nicht viel an für eine moderne IDE-Platte, aber sobald diese Dinger anfangen zu seeken, geht die Performance total in den Keller.
Meine Erfahrungen bei anderen langsameren Rechnern mit alten HDs zeigte, dass fs=32m sich am besten auf die Brenngeschwindigkeit auswirkte. Ich testete damals Audio-CDs. Ich will ja nicht 100% ausschließen, dass da etwas miskonfiguriert war, ich kann es mir aber nicht vorstellen und so wie ich Jörg einschätze, würde er meinen, dass SuSE eine einzige Miskonfiguration ist. Augenblicklich regt er sich ja ziemlich über Linux auf und meint sinngemäß, dass Linus keine Ahnung von Programmieren hat, zB MID
Die Art und Weise, wie der Autor von cdrecord alle möglichen Probleme mit seinem Programm auf das jeweilige Betriebssystem oder die Hardware schiebt, ist mir nicht ganz geheuer. Ich kann jedenfalls keine CDs mit cdrecord schreiben, ohne am Ende vom Einlesen mit dd einen IO-Error zu kriegen (und dann fehlt auch ein kleines Stück am Ende). Er meint es läge an einem read-ahead bug von Linux, und Linus weigere sich ihn zu beheben. (Bei meinen CDs, die ich mit Windows gebrannt habe, gibt's so etwas jedenfalls nicht!). Unter Openbsd funktionierte cdrecord auch nicht richtig wegen einem Bug in Openbsd. usw... Und überhaupt könne man nur unter Solaris richtig arbeiten, meint er. Vielleicht hat er ja sogar recht mit seinen Behauptungen - aber konstruktiv ist das alles nicht gerade. Bei der cdrecord-manpage frage ich mich auch, ob man diese Aussagen wirklich auf alle möglichen Plattformen umlegen kann. Vermutlich bezieht sich der Autor auf eine Sun-Maschine. Vielleicht gelten auf dem PC etwas andere Regeln. Thomas.
Am Sonntag, 28. Dezember 2003 20:46 schrieb Thomas Hofer:
Also mein Rechner war garantiert "idle", als ich schlief :-) Nur fürs Brennen würde ich einen Celeron 1300 mit 512MB RAM und 80GB HD nicht als "underpowered" betrachten, wenn es auch sicher schnellere Rechner gibt.
Der CD-Writer hängt hoffentlich auch einem anderen Kabel als die Festplatte? Mit welcher Geschwindigkeit schreibst du eigentlich?
32 fach wären z.B. 4,8 MB pro Sekunde - das hört sich zwar nicht viel an für eine moderne IDE-Platte, aber sobald diese Dinger anfangen zu seeken, geht die Performance total in den Keller.
Also, das Problem war beim DVD-brennen und ich brannte 2x, das dürfte 18x bei CD sein. 2 HDs hängen an IDE0, Brenner an IDE1-Master und ein CD-ROM am Slave.
Ich kann jedenfalls keine CDs mit cdrecord schreiben, ohne am Ende vom Einlesen mit dd einen IO-Error zu kriegen (und dann fehlt auch ein kleines Stück am Ende). Er meint es läge an einem read-ahead bug von Linux
Ich habe da heute _irgendwo_, also nicht in der Manpage gelesen, dass dieses Problem bei DAO nicht auftreten soll, sondern nur bei TAO. Ich verwende vorsorglich -pad. Man darf -pad nur nicht mit mkisofs-split-output (erzeugt mehrere Tracks) verwenden, sonst gibt es Überraschungen, deren Ursache man nicht so leicht erkennt. Al
Al Bogner wrote: [Sunday 28 December 2003 21:03]
Am Sonntag, 28. Dezember 2003 20:46 schrieb Thomas Hofer:
Also mein Rechner war garantiert "idle", als ich schlief :-) Nur fürs Brennen würde ich einen Celeron 1300 mit 512MB RAM und 80GB HD nicht als "underpowered" betrachten, wenn es auch sicher schnellere Rechner gibt.
Der CD-Writer hängt hoffentlich auch einem anderen Kabel als die Festplatte? Mit welcher Geschwindigkeit schreibst du eigentlich?
32 fach wären z.B. 4,8 MB pro Sekunde - das hört sich zwar nicht viel an für eine moderne IDE-Platte, aber sobald diese Dinger anfangen zu seeken, geht die Performance total in den Keller.
Also, das Problem war beim DVD-brennen und ich brannte 2x, das dürfte 18x bei CD sein. 2 HDs hängen an IDE0, Brenner an IDE1-Master und ein CD-ROM am Slave.
Dir muß klar sein, daß jeder Zugriff auf ein Gerät auf einem IDE-Kanal das andere Gerät auf dem selben Kanal blockiert - und zwar für die gesamte Dauer des Zugriffs. Z.b. man greift auf das CDROM zu, und das muß erstmal anlaufen - dann ist der Brenner unter Umständen für mehrere Sekunden blockiert. Das selbe gilt für die Platten - wenn eine seekt, dann kann die andere auch nicht übertragen. Deswegen haben zwei Platten auf einem ATA-133 Strang nicht jeweils 66 MB/s zur Verfügung, sondern unter Umständen ganz wesentlich weniger, mit teilweise extremen Latenzzeiten. Thomas.
Am Sonntag, 28. Dezember 2003 21:25 schrieb Thomas Hofer:
Dir muß klar sein, daß jeder Zugriff auf ein Gerät auf einem IDE-Kanal das andere Gerät auf dem selben Kanal blockiert - und zwar für die gesamte Dauer des Zugriffs. Z.b. man greift auf das CDROM zu, und das muß erstmal anlaufen - dann ist der Brenner unter Umständen für mehrere Sekunden blockiert. Das selbe gilt für die Platten - wenn eine seekt, dann kann die andere auch nicht übertragen. Deswegen haben zwei Platten auf einem ATA-133 Strang nicht jeweils 66 MB/s zur Verfügung, sondern unter Umständen ganz wesentlich weniger, mit teilweise extremen Latenzzeiten.
Ja, das ist klar und das traf keinesfalls zu. Auf /dev/hda schlummert FreeBSD, für den Fall, dass ich mal mehr Zeit dafür finde. Auf /dev/hdb ist Linux, sowie diverse Partitionen mit Daten und das CDROM wurde sicher nicht verwendet als gebrannt wurde. Brenner und HD hatten also jeweils einen eigenen Bus. Ich bin schon gespannt ob die fs-Option was bringt. Al
Am Sonntag, 28. Dezember 2003 21:49 schrieb Al Bogner:
Ich bin schon gespannt ob die fs-Option was bringt.
Ich probiere gerade remote (verbunden via ssh) eine CD auf einem anderen Rechner zu brennen, d.h. der Rechner ist im Runlevel 5 hochgefahren, es wird aber kein X benutzt. Mem: 255892k total, 251860k used, 4032k free, 852k buffers Swap: 136512k total, 136380k used, 132k free, 8652k cached 169M /brenndaten/TAGESSICHERUNG_c8-031228 du: cannot read directory `/brenndaten/etc_c8-031228/X11/xdm/xdm-errors': No such file or directory du: cannot read directory `/brenndaten/etc_c8-031228/X11/xdm/xdm-pid': No such file or directory 40M /brenndaten/etc_c8-031228 11M /brenndaten/ulb_c8-031228 77M /brenndaten/home_ec_c8-031228 160K /brenndaten/shared_nfs_ec_c8-031228 32K /brenndaten/daten_ec8_c8-031228 Seit 20 Minuten wird nur geswapt, ab und zu läßt sich mkisofs bei top blicken, cdrecord sieht man noch nicht. Mit dem Brennen von etc als graft-point sind mir bis jetzt keine Probleme bekannt, als symlink aber schon. etc_c8-031228=/etc Vielleicht gibt es Probleme mit den Links und mkisofs. Ich werde nun abbrechen und nicht mehr on the fly brennen, sondern die Ausgabe von mkisofs in ein Log umleiten. Al
Am Sonntag, 28. Dezember 2003 23:26 schrieb Al Bogner:
Am Sonntag, 28. Dezember 2003 21:49 schrieb Al Bogner:
Ich bin schon gespannt ob die fs-Option was bringt.
Ich probiere gerade remote (verbunden via ssh) eine CD auf einem anderen Rechner zu brennen, d.h. der Rechner ist im Runlevel 5 hochgefahren, es wird aber kein X benutzt.
Mem: 255892k total, 251860k used, 4032k free, 852k buffers Swap: 136512k total, 136380k used, 132k free, 8652k cached
Ich werde nun abbrechen und nicht mehr on the fly brennen, sondern die Ausgabe von mkisofs in ein Log umleiten.
Ich packe es nicht, was ist denn da mit dem swap los: Mem: 255892k total, 253172k used, 2720k free, 280k buffers Swap: 136512k total, 136504k used, 8k free, 2028k cached Diesmal habe ich aber ein Log: Scanning /etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/opt/gnome/gconf/su/gconf.xml.defaults/schemas/apps/galeon/State/prefs_dialog Scanning /etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/opt/gnome/gconf/su/gconf.xml.defaults/schemas/apps/galeon/State/history_dock Scanning /etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/opt/gnome/gconf/su/gconf.xml.defaults/schemas/apps/galeon/State/js_console Auf einem anderen Rechner gab es keine Probleme mit /etc. Speziell in /home und /etc Verzeichnissen stelle ich _manchmal_ Probleme fest. Irgendwie sieht es danach aus, dass man diese Verzeichnisse unter Umständen nicht 1:1 mit aufgelösten Links brennen kann. Hat wer eine andere Idee als tar? Al
Al Bogner schrieb:
Diesmal habe ich aber ein Log:
Scanning /etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/etc/opt/gnome/gconf/su/gconf.xml.defaults/schemas/apps/galeon/State/prefs_dialog
Auf einem anderen Rechner gab es keine Probleme mit /etc. Speziell in /home und /etc Verzeichnissen stelle ich _manchmal_ Probleme
Das sieht nach einem relativ unnötigem "SuSE-Link" in /etc aus. Zumindest war das "früher" so, ich kenne keine SuSEs nach 7.3 Prüfe doch mal auf den betroffenen Maschinen die Verzeichniss-links in /etc/init.d und /etc/rc.d mfG Carsten
participants (3)
-
Al Bogner
-
Carsten Hesberg
-
Thomas Hofer