Re: [Debian]:Mit Lilo reiserfs booten...
Hi,
On Thu, 24 Feb 2000, Marko Schulz wrote:
> Ich denke es ist klar was Michael meinte. Wenn auf dem Rechner nur der
> Bildschirmschoner bunte Bilder malt und dabei die CPU kräftig belastet
> wird das kaum eine Gefahr darstellen. [...] Aber für die meisten Leute
> geht in den meisten Situationen schon eine hohe CPU-Belastung mit
> einer hohen Plattenaktivität einher.
Stimmt schon, f"ur den gemeinen Benutzer trifft das sicherlich zu. Aber es
gibt auch gen"ugend Einsatzbeispiele, wo die Plattenaktivit"at fast bei
Null liegt; wird halt schnell vergessen.
[Hier stehen unter anderem mehrere 21264er, die fast eine stetige Load von
eins haben, die Plattenzugriffe pro Tag aber noch z"ahlbar sind ...]
> Wenn da was von "zero dtime" (Ich nehme an, daß heißt Delete Time)
> erscheint, dann habe ich auch keine Ahnung was das heißt und die
> Manpage gibt mir ebenfalls keinen Anhaltspunkt.
Deletion time, genau, aber e2fsck kennt noch sooooooooooooooooooooooo
viele andere Phrasen, die man hoffentlich nie zu Gesicht bekommt :)
Bez"uglich dtime: Das kann man so in ein/zwei S"atzen nicht erkl"aren, da
es eine Reihe von Verkn"upfungen bzgl. dieser gibt und dtime nat"urlich
ein wichtiges Moment darstellt.
Aber ein Beispiel: Sollte dtime f"ur / (im Fehlerfall) gesetzt sein, so
will wohl kaum jemand, da"s das gefixt wird (keine Angst, wird
abgefangen). Oder aber auch wenn Links existieren et cetera.
> Wie soll e2fsck etwas reparieren, wenn der Festplatte gerade mitten im
> Schreibvorgang der Saft abgestellt wird?
Kommt darauf an, was GENAU in just diesem Moment geschrieben wurde. Die
Daten per se sind so und so futsch -- auch beim TFS. Das TFS tut sich
allerdings auf Grund der Tatsache leichter, das *vor* dem eigentlichen
Datenstrom die anvisierten "Anderungen im Journal festgehalten werden. Bei
Fehlschlag kann man so leicht feststellen, was betroffen war; deswegen
geht's ja u. a. auch so schnell.
> Zugegeben sollte dadurch kaum ein Programm aus *bin/ zerstört werden,
> da man die selten überschreibt, so daß fdisk diese heil hinterlassen
> sollte.
fdisk? Also so schlimm mu"s es ja nicht gleich kommen >;) SCNR
Im Normalfall sollte dem so sein -- ein Grund, weshalb man /, /usr usw.
auf entsprechende Partitionen verteilen und wenn m"oglich (z. B. bei /usr)
'read-only' mounten sollte. Dann geht nicht nur der Plattencheck
schneller. Nun macht das nicht jeder so und es gibt ja auch noch
'Daten-Partitionen'.
Trotzdem kann es passieren, da"s auch 'benachbarte' (also nicht w"ortlich)
Informationen betroffen sein k"onnen. Aber das w"urde jetzt hier _viel_ zu
weit f"uhren. Wen's interessiert, der soll sich ein bis f"unf B"ucher zum
Design und Struktur von Dateisystemen unter's Kopfkissen legen.
aleX
--
Alexander Wiedeck...............alexander.wiedeck@ku-eichstaett.de
Key fingerprint = 02 C9 F8 08 1A 36 F9 D0 22 6C 4C 4F 06 78 34 C3
I know it all. I just can't remember it all at once.
------------------------------------------------
Um sich aus der Liste auszutragen schicken Sie
bitte eine E-Mail an majordomo@jfl.de die im Body
"unsubscribe debian-user-de <deine emailadresse>"
enthaelt.
Bei Problemen bitte eine Mail an: Jan.Otto@jfl.de
------------------------------------------------
Anzahl der eingetragenen Mitglieder: 727
Reply to: