Hab' ich auch nicht behauptet. Ich tippe einfach auf Verschleiss - nach
5,5 Jahren wahrscheinlich.
Nö, die Akkulade-/Spannungswandlerschaltung rund um die (ehemalige) Netzteilbuchse (ich musste da improvisieren) löst sich anscheinend in Wohlgefallen auf.
Über NTFS kann ich nix sagen, aber gerade die anderen beiden von Dir genannten zeichnen sich dadurch aus, dass sie durch simples ausschalten zu beliebigen Zeitpunkten nicht aus dem Tritt kommen. Das ist kein Zufall, sondern der Fortschritt gegenüber den Vorgängern. Das Zauberwort zum Thema ist "Journaling". Zitat aus Wikipedia:
/------------------------ Ein Journaling-Dateisystem ist ein Dateisystem, welches alle Änderungen vor dem eigentlichen Schreiben in einem dafür reservierten Speicherbereich, dem Journal, aufzeichnet. Damit ist es zu jedem Zeitpunkt möglich, einen konsistenten Zustand der Daten zu rekonstruieren, auch wenn ein Schreibvorgang an beliebiger Stelle abgebrochen wurde. \------------------------
------
--
Kai-Martin Knaak tel: +49-511-762-2895
Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211
Festplatte defekte Sektoren durch Netzausfall? Glob ich nie nich!
Und dass Du Deinen Rechner so ruckartig anheben kannst, dass die Platte defekte Sektoren bekommt (Headcrash?) glaube ich auch nicht. Beim ruckartigen absetzen des Rechners (vulgo fallenslassen aus ein paar cm Höhe) bei laufender Platte sollte das schon eher gehen.
Du müsstest den Rechner auf den Knien einschalten und dann auf den Tisch batzen... Wer sowas macht, hat zu Recht kaputte Sektoren :-P
BTW mein IBM Stinkpad T30 hat extra einen Stoßdämpfer im Boden, damit die Platte nicht so strapaziert wird.
Wobei aber NTFS, XFS, JFS, ReiserFS und ext3 Journaling nur auf Metadatenebene machen. Konsistente Zustände der eigentlichen Daten auf der Platte werden damit nicht garantiert. Das ist aber bei der üblichen Betriebsystem-API zum Schreiben der Daten ohnehin schwer, dazu bräuchte man eher was wie bei Datenbanken mit "commit".
--
Georg Acher, acher@in.tum.de
http://www.lrr.in.tum.de/~acher
meine theorie ist, daß, wenn der saft mitten im schreiben eines sektors ausgeht, dort framing/checksums/ECC oder so nicht mehr paßt und er daher als "defekt" erkannt wird. nach einem überschreiben der kompletten platte mit nullen warens dann wieder weg (was meine theorie unterstützen kann, aber natürlich auch an sector reallocation liegen kann).
jedenfalls hat seit heut früh das serverklo einen eigenen FI-LS, jetzt dürfen die birnen wieder mit lichtbogen durchbrennen.
cm.
--
** christian mock in vienna, austria -- http://www.tahina.priv.at/
Rechtlich gesehen, besteht kein Anspruch auf Weiterleitung von
das ist nur leider theorie. ich hab mit ext3 und xfs schon interessante (im chinesischen sinn) zustände nach crashes gesehen, mit xfs schlimmer als mit ext3. *meistens* gehts gut...
cm.
--
>> [1] MSFP nennt das dann "Hooverbutton",
> ^^^^^^ Weils so gut saugt?
Disziplin reicht aus. Wenn ich arbeite, sichere ich nach jeder bedeutenden Aenderung und bei CAD- oder Doku-Marathons alle fuenf Minuten. Wenn da mal ein File kaputtgehen wuerde, wen juckt das? Natuerlich sollte die Sicherung so aussehen, dass *.bak oder so geschrieben wird.
Gestern vorgekommen, doch den File hatte mein Finger abgeschossen. Schnell den *.bak umbenannt und es ging ungebremst weiter.
Das hat nichts mit Disziplin zu tun, das geht nur per SW-Design. Bei echtem Journaling sind alle zu einer Transaktion gehörenden Files in einem konsistenten Zustand. Wenn man also zB. "Save all" macht, müssten .sch und .brd zum selben Stand gehören. Entweder ist nach dem Crash beides alt oder beides neu. Das müssen noch nichtmal zwei Files sein, zwei gleichzeitig zu ändernde Stellen in einem File reichen auch schon. Ohne eine explizite Klammer wie zB. in SQL mit begin/commit und evtl. rollback kann man das nicht garantieren.
--
Georg Acher, acher@in.tum.de
http://www.lrr.in.tum.de/~acher
Ich hoffe, du hast bei deinen Festplatten den Schreibcache abgeschaltet. Journaling-FS und Writecache bei der Platte vertragen sich nur ganz selten auf Dauer. (ZFS faellt mir hier ein). XFS und JFS scheinen Dateien, die bei einem Crash offen waren und nicht per Journal gefixt werden koennen mit Nullen zu fuellen. AFAIK ein dokumentiertes Feature.
Wenn man es nicht mit "Save All" sondern mit "Save" macht, geht das auch ohne SW Design. Natuerlich muss man auch dafuer sorgen, dass regelmaessig Files auf einen physikalisch anderen Speicher gehen, sonst nutzt einem das alles bei einem HD-Crash nichts.
Mein alter Compaq Contura war mechanisch soweit verschlissen und angebrochen, dass die Batterie nur noch mit Duct Tape (Klebeband fuer Luftschaechte) hielt und bei starken Turbulenzen im Flugzeug trotzdem rausfiel. Nie einen Fileverlust gehabt. OrCad SDT, Word, Works, SPICE, alles unter DOS.
In article , Gerrit Heitsch writes: |> Ich hoffe, du hast bei deinen Festplatten den Schreibcache abgeschaltet.
Nö, trotzdem keine Probleme.
|> Journaling-FS und Writecache bei der Platte vertragen sich nur ganz |> selten auf Dauer. (ZFS faellt mir hier ein). XFS und JFS scheinen |> Dateien, die bei einem Crash offen waren und nicht per Journal |> gefixt werden koennen mit Nullen zu fuellen. AFAIK ein dokumentiertes |> Feature.
JFS hat vor kurzem die Inhalte von Dateien nach einem Crash vertauscht. Das war das KO für das JFS-Experiment.
--
Georg Acher, acher@in.tum.de
http://www.lrr.in.tum.de/~acher
So wie ich das noch gelernt habe, werden beim formatieren die Sektorinformationen eingetragen, Die Daten stehen im Datenbereich der Sektoren. Nur in den Datenbereich wird geschrieben. Also theoretisch kann die Sektorinfo nicht über den Jordan gehen, die Daten können aber kaputt gehen. Wenig lustig im eigentlichen Dateisystem... Du hättest dann ggf. Datenfehler... und den hast Du mit überschreiben wegbekommen.
Wenn latürnich der HD Controller kein vernünftiges Reset bei PWRdown produziert, dann kann alles mögliche passieren. Aber ich hoffe nicht, dass Geiz iss geil, schon soweit fortgeschritten ist.
Ausserdem rechne mal aus, wie schnell moderne Festplatten einen Sektor (512byte) geschrieben haben. Da sollten mickrige Kondensatoren locker die Spannung halten. IIRC ist die interne Transferrate schon in Größenordnungen von 1GBit/sec. Das würde bedeuten, so ein Sektor ist innerhalb 4ns durch wäre. Hoffentlich hab ich mich da jetzt nicht verrechnet. Das scheint alles übelstes HF Voodoo zu sein :-(
Besser is dat :-) Gute Sitzung wünsche ich.
BTW: Was ist der Unterschied zwischen einer Sitzung und einer Besprechung?
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.