|
Diese Diskussion wurde archiviert.
Es können keine neuen Kommentare abgegeben werden.
|
|
|
|
 |
|
|
|
Von Anonymer Feigling am Monday 02. December, 16:11 MEW (#3)
|
|
|
|
|
Genau, 2.4.18 für PPC war/ist der grösste mist..
Wenn mein iBook schlafen geht resultiert das in einem schönen kernel Oops.
Seit 2.4.20-rc5 benh geht es endlich wieder. (Naja.. X reagiert nachher nichtmehr ;) aber auf der konsole..)
insbesondere Firewire war auf x86 mit pre 2.4.19 kerneln UNBRACHBAR.
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Monday 02. December, 17:43 MEW (#4)
|
|
|
|
|
Schade, dass sowas in den stable series passiert. Irgendwie wird ist das Prinzip, neuen Code zuerst genügend lange im unstable zu halten, in letzter Zeit nicht mehr wirklich umgesetzt.
Naja, es gibt schlimmeres... :)
|
|
|
|
|
|
|
| |
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 03. December, 11:15 MEW (#9)
|
|
|
|
|
Vielleicht liegt's ja an mir (magischer Einfluss meinerseits), aber ich habe mit ext3 äusserst schlechte Erfahrungen gemacht, was Datenintegrität anbelangt - und dabei meine ich nicht den ganz normalen und erwarteten Effekt, dass Daten standardmässig nicht ge-journal-t werden.
Wer Lust hat: Ich habe hier noch Filesysteme, auf denen nach Crashes Dateien existieren, die sich auf Zugriffsversuche nur noch mit "Input/Output error" melden, ich habe Systeme erlebt, wo nach einem Stromausfall Dateien gefehlt haben oder korrumpiert waren, auf die mit Bestimmtheit in den letzten Wochen nicht schreibend zugegriffen wurde (cool, wenn aus /lib/modules Dateien verschwinden). Kernel: 2.4.7, 2.4.9, 2.4.18
Der Entwickler von ext3 muss da 'was grundsätzlich falsch verstanden haben: Journal => Erhöhung der Zuverlässigkeit, nicht umgekehrt. Jedenfalls habe ich solche Effekte noch bei keinem anderen journalling FS erlebt (Solaris/UFS, XFS, VFS).
|
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 03. December, 11:23 MEW (#10)
|
|
|
|
|
VFS??
äh.. ev. hast du grundsätzlich was garnicht verstanden, was VFS ist....
Wenn ein programm daten generiert, die im RAM hat und während des schreibens fällt der strom aus, dann kann kein journal der welt die daten zurückbringen.
Das journal hilft nur zu wissen, WAS schon erledigt wurde, dass daten von alleine verschwinden ist natürlich nicht schön, ist mir aber noch nie passiert.
Für ext3 spricht eigentlich ja nur, dass es einfach zu installieren ist.
Ansonsten mag ich ReiserFS wirklich sehr..
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 03. December, 12:00 MEW (#11)
|
|
|
|
|
Erst lesen, dann verstehen und erst dann antworten.
1) VFS: "Veritas File System" - ein Journalling File System
2) Ich hatte explizit erwähnt, dass der Effekt bei nicht veränderten Dateien aufgetreten ist - also nix von wegen RAM und Buffers. Natürlich weiss ich, dass ein Journalling FS normalerweise die Datenintegrität nicht garantiert - das hatte ich ja auch geschrieben. Darum geht es hier nicht.
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 03. December, 13:30 MEW (#13)
|
|
|
|
|
Ein häufiger Grund für das nicht-Beheben derartiger Bugs ist der Versuch, sie "wegzureden" und sporadische Probleme mit kosmischer Strahlung (ja, könnte vorkommen :-)) oder Schwankungen des Erdmagnetfeldes erklären zu wollen.
I/O-Error: In diesen Fällen definitiv keine HW-Fehler - ich habe es auf ziemlich vielen unterschiedlichen Systemen angetroffen (Selbstversuch: find / -ls); da das Problem beim Zugriff auf den Inode (readdir() geht, stat() nicht) zu entstehen scheint und nicht etwa beim Zugriff auf den eigentlichen Dateiinhalt handelt es sich ausserdem um einen extrem unwahrscheinlichen HW-Defekt (Platten gehen normalerweise Sektor-, Zylinder-, oder Plattenweise kaputt, kaum je Inode-Weise) und ausserdem loggt zumindest mein System Diskfehler normalerweise per syslog.
Bei der Erhöhung der Zuverlässigkeit hast Du insofern unrecht, als das Journal garantiert, dass die FS-Verwaltungsstrukturen auf der Disk anhand des Journals (nicht die Daten) jederzeit in einen konsistenten Zustand überführbar sind, also durch einen Crash nicht zerschossen werden können. Dateien sind also entweder da (konsistent) oder nicht da (konsistent), aber nicht für Monate da und plötzlich nach einem Reboot nicht mehr da (inkonsistent) - es sei denn natürlich, man löscht sie (soll auch vorkommen :-)). Weder von einem loggenden noch von einem herkömmlichen Dateisystem erwarte ich allerdings, dass Daten in Dateien, die längere Zeit (Wochen) nicht beschrieben wurden, korrumpiert werden (na ja, bei einem nicht-loggenden System gibt's denkbare Szenarien).
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 03. December, 14:23 MEW (#15)
|
|
|
|
|
Schreibfehler durch fehlerhafte Treiber und eine darauf folgende FS-Inkonsistenz wären natürlich eine mögliche Erklärung. Das Problem mit den verschwundenen/fehlerhaften Daten habe ich allerdings quer über Systeme mit IDE, SCSI und Hardware-RAID gesehen, beim I/O-Error-Problem wäre ich mir nicht ganz sicher, ob es nicht auf IDE-Systeme beschränkt wäre - die Kisten, bei denen ich den Effekt sicher gesehen habe, haben alle IDE-Laufwerke.
|
|
|
|
|
|
|
