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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] die im Body "unsubscribe debian-user-de <deine emailadresse>" enthaelt. Bei Problemen bitte eine Mail an: [EMAIL PROTECTED] ------------------------------------------------ Anzahl der eingetragenen Mitglieder: 727
