From: Raphael Becker (beckerra_at_rumms.uni-mannheim.de)
Date: 20. Mar 2000
Juergen Roethig wrote:
> > > Was bringt das eigentlich alles für Vorteile? *genau-erkundige*
> > Normalerweise Sicherheitsaspekte.
>
> Diese "Sicherheitsaspekte" sind ja wohl ein Totschlag-Argument, aber
stimmt. Tut mir leid.
> der bei Produktionssystemen viel wichtigere) Aspekt ist aber die
> Verkuerzung der "Totzeit" - wenn Dir Dein System abschmiert, musst Du
> beim Hochfahren erst einmal alle Filesysteme checken (und das dauert bei
> einem Non-journaling-Filesystem wie beispielsweise ext2 und grossen
> Partitionen im mehrere-GB-Bereich durchaus seine Zeit). Wenn die Platte
Ich weiß ... das meinte ich auch.
Ich hab das halbe Wochenende mit "fsck /dev/sda[1-8]" zugebracht, weil
ein Sektor in /usr "defekt" ist/war.
Das System hat sich dann mit SCSI-Error/SCSI-Reset "verabschiedet".
Vielleicht sollte man hier noch erwähnen, daß es ganz nützlich ist,
den MagicSysKey im Kernel einzukompilieren. Damit ist es auch unter
sehr kritischen Bedingungen (zB alle Prozesse blockiert, weil System
mit SCSI-Reset dauer-beschäftigt ist), das System halbwegs konsistent
runterzufahren.
Unter file:///usr/src/linux/Documentation/sysrq.txt steht mehr zum
Thema, meine "Notfallsequenz bei SCSI-Problemen" ist "T"(erminate)
"K"(ill) "S"(ync) (mehmals) "U"(mount) (evtl auch mehrmals) und zum
Schluß "B"(oot)
Natürlich zusammen mit "Alt"+"Druck"+"Taste" (gleichzeitig halten).
Das führt dazu, daß zwar die Filesysteme "unsauber" abgebrochen
werden, allerdings das Risiko, daß eine Inkonsistenz zurückbleibt
erheblich reduziert wird (je nachdem, ob der Controller die Platte
überhaupt noch irgendwie ansprechen konnte).
Allgemein ist der MagicSysKey eine Art Kernel-Mini-Debugger, man kann
sich zB auch aktuelle Speicherinformationen anzeigen lassen. Mit "W"
bekommt man eine Liste aller "Hotkeys".
Sehr nützliches Feature, allerdings sehr mit Vorsicht zu genießen!
> mehreren ext2-Partitionen, Reset druecken, Maschine braucht sehr lange
> beim Hochfahren (e2fschk) - wenn dagegen einzelne Partitionen vorher
3 Platten, 9GB SCSI und 2x10GB EIDE (werden parallel gecheckt) dauert
insgesamt meist ca 20 min, wenn Fehler auftreten oft erheblich länger.
Durchschnittliche Plattenfüllung so um 70-90%, je nach Partition.
Meine Erfahrungswerte.
> > In der Praxis (auf "Einzelplatzsystemen" und so) wird das allerdings
> > nicht gemacht... also ich machs nicht, weil dann alles sehr unflexibel
> > wäre.
>
> In der Praxis (auch auf "Einzelplatzsystemen") ist das remounten auf
> "read-only" aber ebenfalls ein probates Mittel, um moegliche
> Filesystem-Inkonsistenzen zu minimieren, wenn bei einem (aufgrund
> irgendeines Fehlers) instabilen System ein geordnetes Runterfahren nicht
> mehr, aber die Eingabe von Befehlen (auf einer hoffentlich verfuegbaren
> Konsole mit root-Rechten) doch noch moeglich ist.
Hmm, aber selbst root bzw root-Prozesse haben keinen Schreibzugriff
auf ein ro-gemountetes Medium. Deshalb meinte ich, daß es sehr
unflexibel ist.
Natürlich ist es das allersicherste (in Bezug auf Absturzsicherheit
bzw Risiko von Inkosistenzen), wenn man derartige Partitionen ro
mountet und an sich ist das ja auch so vorgesehen (deswegen ja auch
die Unterscheidung von /usr und /var)
Gruß
Raphael Becker
-- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! http://signature.home.pages.de/
Dieses Archiv wurde generiert von hypermail 2.1.2 : 11. Mar 2002 CET