Es kommt mir so vor, als wüsstet ihr nicht warum man das OS runterfahren muss ... Noch nie was von Datenträger-Caches gehört, deren Inhalt vielleicht auf die Festplatte geschrieben werden müssen, bevor man den Stecker zieht um Datenverlust zu vermeiden?
Mit SmartDrive unter DOS hätte man genaugenommen das DOS auch runterfahren müssen ...
Mfg
Thomas
Hallo Thomas,
Ein gutes OS bleibt dennoch stabil. Wenn der Verlust der Caches beim naechsten Einschalten zu unstabilem Verhalten des OS fuehrt, ist es meiner Meinung nach schlicht ein schlechtes OS.
Tat ich nie und es gab nicht einen Mucks in 15 Jahren. Mit Win 3.1 uebrigens auch nicht, aber das hatte ich wenig benutzt. Die Erfahrung mit dessen Nachfolger war allerdings herbe. Der Absturz geschah bereits nach dem ersten Wiedereinschalten.
Gruesse, Joerg
Jedes moderne OS muss aber eben deswegen heruntergefahren werden. Es sind ja nicht nur die Caches die noch auf Festplatte geschrieben werden müssen sondern auch Hintergrundprogramme die benachichtig werden wollen das der Computer jetzt ausgeschaltet wird um ihrerseits Daten zu sichern oder Verbindungen zu beenden.
Wenn du ein schlechtes OS nur an diesem Punkt festnagelst fallen schon mal alle Multitasting OS's raus. Und streng genommen stimmt das auch bei DOS schon nicht mehr wenn du mitten im Editieren einer Datei den Computer ausschaltest und nacher erwartest das nix verlohren gegangen ist.
Und wenn du ein sauberes Hochfahren nach Absturz erwartest wird dir das von den meisten Betriebssystemen gewährleistet so du nicht gerade was am Kernel gemacht hast. Aber Linux mit ext2 hat u.U. beim prüfen der Festplatte und Fehlern die zu Datenverlust führen werden nachgefragt so das doch jemand vor Ort sein musste und man es nicht remote machen konnte.
Aber ich glaube das du die Behauptung sowieso nur provokanterweise aufgestellt hast.
Tschüss Martin L.
Ja. Aber somit hat er, und auch du, alle modernen Betriebssysteme über einen Kamm geschert. Selbst mit einem modernen Dateisystem wie ext3 oder reiserfs kann es vereinzelt vorkommen das das Dateisystem in einen Inkosistenten Zustand verfällt.
Und u.U. ist auch gar nicht das Betriebssystem dafür verantwortlich sondern die Festplatten, so der Schreibcache aktiviert wurde. (Ich glaube nämlich nicht das diese beim trennen der Stromversorgung genug Reserven haben um noch 8MByte auf die Platte zu schreiben)
Nein. Ihr betrachtet das zu undifferenziert. Es gibt immer einen worst case in dem das beste Betriebssystem nicht mehr zuverlässig arbeiten kann nachdem der Strom ausgefallen ist. (Und ich meine Betriebssystem und keinen besseren Bootloader wie DOS) Das habe ich auch schon von ext3 gehört. Nur ist es da natürlich sehr unwarscheinlich.
Tschüss Martin L.
Martin Laabs wrote: > "MaWin" writes: > > "Martin Laabs" schrieb: > > > Aber ich glaube das du die Behauptung sowieso nur provokanterweise > > > aufgestellt hast. > > > > Rechner, die 'heruntergefahren' werden muessen, weil sie sonst > > inkonsistente Daten auf der Platte haben koennen, die den naechsten > > Start verhindern, sind uebelster Schrott. > > Ja. Aber somit hat er, und auch du, alle modernen Betriebssysteme > über einen Kamm geschert.
Ich glaube eher, hier werden zwei Dinge durcheinander ge- bracht:
Dem ersten Punkt stimme ich zu, dem zweiten allerdings nicht uneingeschränkt. Es gibt Spezialfälle, wo das OK ist, aber im allgemeinen sollten die auf einem Rechner laufenden Programme (und das OS selbst) es mitbekommen, wenn der Rechner heruntergefahren wird, um etwa Status- daten zu sichern usw.
Das sollte aber nicht vorkommen, sonst ist es ein Bug. Bei FreeBSD z.B. garantiert Soft-Updates grundsätzlich die Konsistenz, vorausgesetzt, die Festplatten sind vernünftig implementiert (z.B. Tagged-Command-Queuing), damit das Be- triebssystem feststellen kann, welche Schreiboperationen tatsächlich durchgeführt wurden.
Bei pfuschiger Festplatten-Firmware (was gerade bei IDE/ATA leider keine Ausnahme ist) kann natürlich auch das beste OS nichts ausrichten.
Der Schreib-Cache spielt keine so große Rolle, wenn die Festplatte Tagged-Command-Queuing korrekt unterstützt.
Da gab's früher ziemlich clevere Tricks. Einige Platten konnten den Spindelmotor als eine Art Dynamo verwenden und so den Restdrehimpuls nutzen, um genug Energie zu erzeugen, um die Cachedaten wegzuschreiben (auf eine spezielle Spur, damit möglichst nicht mehr viele Spurwechsel gemacht werden müssen; bei nächsten Start wurden dann diese Daten wieder an die eigentlichen Zielpositionen verteilt). Ich glaube aber nicht, daß das bei heutigen Platten noch gemacht wird.
Andererseits wird der überwiegende Teil des Caches einer Platte eher als Lesecache verwendet, und nur ein kleinerer Teil als Schreibcache. Darüberhinaus sind moderne Platten so schnell, daß das Wegschreiben des Caches nur im Bereich von 100ms dauern dürfte. Für diesen kleinen Zeitraum dür- fte sich genug Restenergie für die Elektronik puffern las- sen (die Plattenspindel hat eh genug Drall, so daß sie für diese 100ms ohne Antrieb auskommt).
Gruß Olli
"Martin Laabs" schrieb im Newsbeitrag news: snipped-for-privacy@uni-berlin.de...
Ich schrieb schon, das selbst ein transaktionales Dateisystem voraussetzt, das es von der Applikation richtig verwendet wird.
Festplatten muessen von einem transaktionalen Dateisystem so angesprochen werden, das bei notwendigen Transaktionssschritten (also ev. vor 8MB) ein flash gesendet wird. Das verstehen auch die Platten.
Natuerlich gibt es immer die Moeglichkeit, alles falsch zu machen, aber man muss ja nciht so dumm sein.
Spielt keine Rolle, unvollstaendige Transaktionsschritte duerfen unvollstaendig auf der Platte stehen.
Falsch. Es geht sehr wohl. Been there - done that sagt Oliver dann wohl.
Es gibt immer die Mogliechkeit, falsch zu programmieren.
"Oliver Fromme" schrieb im Newsbeitrag news: snipped-for-privacy@uni-berlin.de...
Welche sollte das sein? Ich halte das für ein Märchen. Allerdings gibt es da noch eine 2. Story. Die behauptet, dass die Drehenergie benutzt wurde, um die Köpfe zu parken. Letztere klingt glaubwürdiger, weil das Schreiben der Daten während schnell abfallender Drehzahl sehr viel aufwendiger und gefährlicher ist, als das Bewegen der Köpfe in eine Parkposition, bei der über eine Rampe die Köpfe von der Plattenoberfläche abgehoben werden, oder wenigstens auf einen Bereich ohne Daten landen.
Ich glaub schon.
Kommt auf die Definition von "Start verhindern" an. Man konnte z.B. die Startskripte von Linux schon vor Jahren so modifizieren, daß ein nicht sauber abgeschlossenes Filesystem automatisch repariert wurde und der Rechner irgendwie wieder hochkam. Nur hat das mit gutem Grund kaum jemand gemacht: "automatisch repariert" kann auch "Platte weitgehend leer" bedeuten.
Aber wenn die fragliche Maschine z.B. ein Datenbankserver ist, dann ist das Hochfahren des Betriebssystems der kleinste Faktor. Viel wichtiger ist die Frage: "ist die Datenbank noch konsistent?", "Wieviele (welche) Transaktionen sind verloren gegangen?" usw.
Die Forderung, solche Systeme müßten kalt abschaltbar sein, würde ich durchaus als provokant bezeichnen.
Gibts seit Jahren. Nennt sich "journaled Filesystem". Aber das hilft dir auch nicht, wenn nicht auch die Applikation deine ungesicherten Änderungen *regelmäßig* wegschreibt. Es ist eigentlich immer ein Problem der Applikation: ein offenes, halb geschriebenes File kann nun mal nicht jede Applikation vertragen. Defensive Strategien wie "um ein File zu speichern, schreib in eine Kopie und benenne erst die fertige Kopie um" sind anscheinend auch kein Allgemeingut.
Im Gegenteil! Gerade bei der Verwendung von Journaling darf die Platte nix verzögert schreiben. Schließlich ist auch das Journal nur ein Stück Plattenspeicher.
XL
Frueher (TM)(r)(c) gab es sowas in exzessiv: Auf der VAX z.B. gab es einen Editor (ich weiss jetzt nicht mehr obs EDT oder EVE war...) der speicherte in einem Journal-File alle Eingaben ab, damit war es nach einem Crash (Ja, auch VAXen koennen crashen) moeglich die Tipparbeit wiederzuholen, und schon das Betriebssystem hat beim Abspeichern dafuer gesorgt dass die neue Version des Files wirklich neu geschieben wurde und eine neue Versionsnummer bekam.
"Axel Schwenke" schrieb im Newsbeitrag news: snipped-for-privacy@idefix.xl.local...
Kann man nicht...
...wie du selber schon bemerkst.
Klare Antwort: Bis zum Zusammenbruch KEINE. Ab dem Zusammenbruch ALLE. Beim Neustart kann klar gesagt werden, das bis Nr. xxx alle Transaktionen gespeichert wurden, und die Datenbank ist IMMER konsistent.
Das ist mein ueblicher Test, wenn jemand von zuverlaessigen Systemen redet. Stecker rausziehen. Du siehst am Gesichtsausdruck, ob der Typ vorher von seiner Aussage ueberzeugt war.
Jein, ein Journal ist EINE Moeglichkeit so was hinzubekommen, muss aber nicht unbedingt auch transaktional werden (bei Linux hat man es z.B. verpfuscht).
Stand im Ursprungsposting: Der WORD-Text ist weg, zumindest seit dem letzten Autosave.
Bei transaktionalen Dateisystemen kein Problem. Ich merke, das dir der Begriff offenbar inhaltlich unklar ist.
Das ist aber eine Variante, ein transaktionales Dateisystem zu bauen (die ich damals verwendet habe).
Bei transaktionalen Dateisystemen kein Problem. Ich merke, das dir der Begriff offenbar inhaltlich unklar ist.
Vom Cache erwarte ich allerdings, dass er von sich aus innert einiger Sekunden mal auf die Idee kommt, die Daten tatsächlich mal auf Disk abzulegen.
Hallo Martin,
Nein, haben wir nicht. Sieh mal bei dieser Firma nach, denn die kann es:
Deren Betriebssytem haben wir so durch die Mangel gedreht, dass unseren SW Ingenieuren fast schlecht dabei wurde. "Aber das koennt ihr doch nicht machen..." Anzahl der Probleme nach dem x-ten Herausziehen des Steckers und anderen hineingeworfenen Knueppeln: Null. Das gleiche haben wir mit anderen Systemen getan und sie dann alle abgelehnt.
Es ist keine undifferenzierte Betrachtungsweise. Wir erwarten einfach nur das, was wir von anderen technischen Objekten wie etwa Autos oder Fernsehern ebenso erwarten. Naemlich dass sie nach abruptem Ausfall der Energiequelle nicht betriebsuntauglich werden. Das ist wohl nicht zuviel verlangt.
DOS ist schon ein wenig besser als nur ein Boot Loader. Es hat mir mehr als ein Jahrzehnt mein Business auf Schwung gehalten und tut es immer noch. Ich konnte damit das gleiche machen wie heutzutage mit Windows. Nur meist schneller.
Gruesse, Joerg
Wenige Sekunden sind schon zu lang.
Wobei bei echten Servern entweder der Schreibcache der Platte abgeschaltet ist oder da eine wirklich dicke USV vorhanden ist. Deren Batterie wird hin und wieder getestet und wenn sie den Test nicht besteht wird der Cache abgeschaltet. Bremst natuerlich etwas, ist aber wirklich die einzige Moeglichkeit sicherzustellen, dass das OS immer genau weiss was nun auf der Platte steht und was nicht.
Gerrit
Hi Manfred,
ROFL. Genau das ist der Test. Ein System, dass diesen nicht uebersteht, hat in kritischen Applikationen nichts zu suchen. Der Ingenieur von QNX aus Kanada sah bei diesem Test gelassen zu, mit einem Pott Kaffee in der Hand. Die Leute von einer anderen (groesseren) Firma wussten nicht einmal, wieviele Mikrosekunden die garantierte maximale Interrupt Latency deren Betriebssystems war.
Gruesse, Joerg
Hallo Rolf,
Und dass er am Ende eine "Alles in Ordnung" Signatur hinterlaesst. Weiterhin sollte auf wechselnde Bereiche geschrieben werden, damit immer eine "last valid copy" vorhanden ist. Warum sich Programmierer mit so etwas so schwer tun, weiss ich nicht. Vielleicht sollten alle mal erst ein Praktikum bei Boeing oder einer anderen Firma machen, deren Boardsysteme unter keinen Umstaenden jemals ausfallen duerfen. Auf der Uni scheinen sie das ja nun nicht zu lernen.
Gruesse, Joerg
Nein. Strom kann ausfallen, Hardware kann den Geist aufgeben. Das passiert normalerweise ohne Warnung. Ein als 'wichtig' bezeichnetes System muss das _ohne_ Datenverlust abkoennen.
Gerrit
Ich schon... Hardware ist zu zuverlaessig geworden und Stromausfaelle gibts auch nicht mehr oft genug.
Gerrit
"Steffen Koepf" schrieb im Newsbeitrag news: snipped-for-privacy@news.in-ulm.de...
Nein, kein historisierendes/versionierendes Dateisystem (gibt's auch, z.B. VMS) sondern eben ein transaktionales: ENTWEDER eine Reihe von Aenderungen (zwischen zwei Zeitpunkten, dem open und close einer Datei) ist komplett gemacht worden, ODER die Datei ist 'nach aussen hin' noch unveraendert. Das Dateisystem und die Dateiinhalte (und die Verzeichnisse) sind also immer konsistent. Die free-list wird eventuell beim fschk/chkdsk aufgeraeumt.
Ja, ich denke so hiess es.
: Da war es nie das Ziel, die eigentlichen Dateiinhalte konsistent zu
Aber es wurde damit zu einem bedauernswerten Beispiel, das journaling nicht mit transaktional gleichzusetzen ist.
"Gerrit Heitsch" schrieb im Newsbeitrag news: snipped-for-privacy@laosinh.s.bawue.de...
ZUVERLAESSIG ?!?!
PC's von heute sind ja wohl was Zuverlaessigkeit anlangt eine Frechheit sondergleichen.
Manche Teil gehen nur 'zufaellig', bei mir z.B. WLan (trotz gutem Empfang).
Dann muessen regelmaessig die Verschleissteile gewechselt werden (Luefter), sonst gibt es 'Motorschaden' am Athlon.
Da halten kaum irgendwelche Netzteile mehr als 3 Jahre durch, bevor die Eko den Deckel aufmachen. Selbst bei Mainboards.
Da zeigen ganze Subsysteme Fehlfunktion (bei mir z.B. das SE515 DSL-Modem von Siemens und USB CardReader).
Und das Betriebssystem hat dokumentiert mehr als 65000 Fehler.
Nein, vergiss Zuverlaessigkeit. Unser 286er hat eine Uptime von ueber 10 Jahren. Vermutlich ist der 15 Jahre alt und laeuft und laeuft und laeuft und laeuft....
DAS nenne ich zuverlaessig.
Hallo Gerrit,
Du kannst Dich bestimmt noch an die Garagentoroeffner in USA erinnern. Es gibt hier erstaunlich viele Leute, die sich nie Gedanken darueber gemacht haben, wie man denn das Auto bei Stromausfall hinausbekommt. Bis es dann auf einmal passiert. Fuer den ersten Fall hatte es gereicht, dass jemand einen Unfall abwehren wollte und dabei einen Holzmast traf. Spaeter hatten wir dann eine hausgemachte Energiekrise, weil die Politiker hier nicht rafften, dass Wachstum ohne hoehere Generatorenkapazitaet nicht geht. Auf Ingenieurs-Amerikanisch: "Duh".
Ach ja, und dann lernte Otto Normalverbraucher noch ganz schnell, dass die vielgepriesenen Drahtlostelefone bei Stromausfall auch nichts nutzen. Bei weitflaechigem Ausfall ist dann auch noch das GSM Netz zerloechert. Ja, in welcher Kiste ist denn der alte Fernsprecher von vor zwanzig Jahren? Auch ein gerade angefeuerter Holzofen ist nicht ohne, wenn die Ventilatoren stehen bleiben und man sich keinen Backup-Wandler besorgt hatte. Da ist es kein grosses Wunder, das junge SW Ingenieure genauso wenig Vorsicht walten lassen.
Bei uns geht es da munter weiter. Selbst CAD Arbeiten koennte ich, wenn ich wollte, einige Wochen per Batterie mit einem guten alten und sparsamem DOS Laptop fortsetzen, der sich mit ein paar Watt begnuegt. Der ist seit Anschaffung Anfang der 90er nicht abgestuerzt, sogar als einmal mitten bei der Orcad-Eingabe der Flieger in ueble Turbulenz geriet und der Akku herausfiel. Da habe ich einfach die letzte Sicherungskopie wieder geladen und der Arbeitsverlust belief sich auf fuenf Minuten. Der gebrochene Akkuschacht wurde solange von einem Schnuersenkel plus ein paar Servietten festgehalten.
Gruesse, Joerg
Have something to add? Share your thoughts — no account required.
Ask the community — no account required