Ja, und nein. Auch ein Journal muss kein 100%iger garant sein das alles stimmt. Es stellt ja an sich nur sicher das es bei Problemen beim schreiben keine Daten verliert. Aber es können ja auch andere Fehler auftretten, z.B. ein Bug in der Dateisystemimplementierung, oder auch ein Hardwarefehler. Gerade in letzterem Fall kann es sehr gut passieren das es vom Dateisystem selbst nicht erkannt, und erst ein Komplettcheck zeigt wenn etwas nicht stimmt.
Ja aber Hardwarefehler sollten eigentlich über SMART erkannt werden und zwar - im laufenden Betrieb und ohne zusätzliche Zeitaufwand - tlw. soweit möglich schon im Vorfeld, bevor also tatsächlich Datenverlust auftritt
leider läuft der smartd wohl nur auf wenigen Systemen, viele fühlen sich hier durch fsck sicher, der leider erst anzeigt wenns zu spät ist. Tja auch unter Linux gibt es eben zunehmend falsch/schlecht informierte User.
Ext 3 ist mir schon mehrmals ohne besonderen grund um die Ohren geflogen, tux sei dank hat mich dieser check beim booten vor dem schlimmsten bewahrt und ich konnte die 300 inodes durch permanentes drücken von "y" "reparieren"...
Software ist fehleranfällig und beinhaltet fehler und das ist bei fast jeder software so und genau deswegen muss man Kontrollen durchführen.
Ansonsten sieht das nämlich wie bei Microsoft Windows aus: Dein System fragmentiert dir deine Dateien unterm hintern und nebenbei geht das Dateisystem auch noch hopps und keiner merkts bis es zu spät ist und das ganze ding nicht mehr starten will
Und zu SMART: Meine Festplatte wird von keinem verfügbaren Smarttool erkannt bzw. richtig ausgelesen (laut den dingern dürfte meine festplatte nicht mehr funktionieren) soviel dazu...
Da kann man sagen was man will (und leider ist es erst seit Suse 11.0 anders). Das Reiser fs war aus der Benutzer Sicht ein verflucht gutes Dateisystem. Ich weiss nicht wie lange ich dieses System auf wie vielen Rechner benutzt habe, und zum Teil auch immer noch benutze. Mir ist in all diesen Jahren nicht ein einziges Reiser in den Reperaturstatus gegangen und das obwohl ich teilweise den Larry hab raushängen lassen und die Systeme mal kurz ausgeschaltet habe.
Unsinn. Wir hatten eine ganze Weile 'nen Fileserver mit reiserfs laufen, der staendig einfach im laufenden Betrieb ausgeschaltet wurde ohne ihn korrekt runterzufahren, da das Buttonmodul unter einem 2.4er-Kernel nicht richtig funktionierte. Gab trotzdem keine Probleme.
Das wird einiger Wahrscheinlichkeit nach an etwas anderem gelegen haben. Ich habe schon mehrfach bei Systemen mit ReiserFS den Stecker gezogen und danach ohne Probleme wieder hochgefahren.
Ich habe auch jahrelang Reiser benutzt, und es ist aus Benutzersicht wirklich ein verflucht gutes Dateisystem, solange nix passiert... Durch einen Motherboardfehler stürzte der PC ab, das Dateisystem nicht mehr lesbar und ich kann dir versprechen: bei einem Reiser den Tree zu rebuilden weil dir (Hardware/Strom weg) ist die Hölle schlechthin. Die "Ausbeute" ist im Vergleich zu ext3 auf grund der B-Tree Struktur miserabel, noch höflich ausgedrückt (aus eigener Erfahrung, selber PC annähernd selbe Daten, Stromausfall). Das binäre Suchen von Daten innerhalb Dateifragmenten bleibt dir bei einem gekräschtem Reiser nie erspaart. Ext3 ist da stählener. Es gibt einfach mehr gut geschriebene Tools, und Sicherungshaken eingebaut im System. Im Falle des Falles hast du einfach um ein vielfaches mehr Möglichkeiten. Fazit: solange es läuft prima, aber ein Problem und es lässt die Hose runter...
# aber Hardwarefehler sollten eigentlich über SMART erkannt werden Stört dich das eigentlich und das tlw. gar nicht. ;-) Nichts ist perfekt und wenn ich mich nicht irre, gibt es auch Ausfälle, die smart nicht erkennt. (Meine da stand mal was in einer der Linux- Zeitschriften.)
> In der Praxis ist SMART sowas von unzuverlässig Dem kann ich nur zustimmen. Ich kenne einige klar defekte Festplatten, die von Smart noch als OK bezeichnet werden. Da fragt man sich schon, was das Ganze soll, wenn nicht einmal offensichtliche Defekte angezeigt werden. Naja.
falsch. Es stellt einfach nur sicher, daß die Struktur gewährleistet bleibt und das Dateisystem konsistent ist. Die Daten können dabei schonmal verloren gehen. Dazu kommt, daß ext3 im falschen Moment unterbrochen, durchaus Unsinn verzapfen kann. Verschlimmernt kommt hinzu, daß bei ext3 per default barrier aus sind - schließlich interessiert kein Schwein, ob die Daten es auf die Platte schadden oder das fs in Ordnung ist - hauptsache Geschwindigkeit! ...
wenn einem an den Daten liegt, nimmt man sowieso lieber reiserfs oder xfs.... die haben barrier an - und sind dann deutlich schneller als ext3, wenn man das dort auch aktiviert.
"falsch. Es stellt einfach nur sicher, daß die Struktur gewährleistet bleibt und das Dateisystem konsistent ist"
Das ist doch genau, was beim Check regelmäßig überprüft wird, zur Datenintegrität kann fschk auch keine Aussagen treffen. Redundant und lästig, jedenfalls habe ich hier noch kein bestechendes Argument gehört, wo der Vorteil der regelmäßigen Checks liegen soll. Mein xfs macht sowas übrigens nicht und ich glaube noch immer, dass man das einfach aus Gewohnheit von ext2 übernommen hat.
Nein, den wie gesagt kann die Datenstruktur auch am Journaling vorbei beschädigt werden.
Mögliche Ursachen die mir spontan einfallen 1. Fehler in der Implementierung des Dateisystems 2. Hardwarefehler der HDD 3. Eine andere Implementierung mountet das Dateisystem und beschädigt es
Aber es können ja auch andere Fehler auftretten, z.B. ein Bug in der Dateisystemimplementierung, oder auch ein Hardwarefehler. Gerade in letzterem Fall kann es sehr gut passieren das es vom Dateisystem selbst nicht erkannt, und erst ein Komplettcheck zeigt wenn etwas nicht stimmt.
- im laufenden Betrieb und ohne zusätzliche Zeitaufwand
- tlw. soweit möglich schon im Vorfeld, bevor also tatsächlich Datenverlust auftritt
leider läuft der smartd wohl nur auf wenigen Systemen, viele fühlen sich hier durch fsck sicher, der leider erst anzeigt wenns zu spät ist. Tja auch unter Linux gibt es eben zunehmend falsch/schlecht informierte User.
Fällt dir was auf? Das ist alles relativ.
Ext 3 ist mir schon mehrmals ohne besonderen grund um die Ohren geflogen, tux sei dank hat mich dieser check beim booten vor dem schlimmsten bewahrt und ich konnte die 300 inodes durch permanentes drücken von "y" "reparieren"...
Software ist fehleranfällig und beinhaltet fehler und das ist bei fast jeder software so und genau deswegen muss man Kontrollen durchführen.
Ansonsten sieht das nämlich wie bei Microsoft Windows aus: Dein System fragmentiert dir deine Dateien unterm hintern und nebenbei geht das Dateisystem auch noch hopps und keiner merkts bis es zu spät ist und das ganze ding nicht mehr starten will
Und zu SMART: Meine Festplatte wird von keinem verfügbaren Smarttool erkannt bzw. richtig ausgelesen (laut den dingern dürfte meine festplatte nicht mehr funktionieren) soviel dazu...
Hatte ich bei ext2/3 noch nie.
Durch einen Motherboardfehler stürzte der PC ab, das Dateisystem nicht mehr lesbar und ich kann dir versprechen: bei einem Reiser den Tree zu rebuilden weil dir (Hardware/Strom weg) ist die Hölle schlechthin. Die "Ausbeute" ist im Vergleich zu ext3 auf grund der B-Tree Struktur miserabel, noch höflich ausgedrückt (aus eigener Erfahrung, selber PC annähernd selbe Daten, Stromausfall). Das binäre Suchen von Daten innerhalb Dateifragmenten bleibt dir bei einem gekräschtem Reiser nie erspaart.
Ext3 ist da stählener. Es gibt einfach mehr gut geschriebene Tools, und Sicherungshaken eingebaut im System. Im Falle des Falles hast du einfach um ein vielfaches mehr Möglichkeiten.
Fazit: solange es läuft prima, aber ein Problem und es lässt die Hose runter...
Stört dich das eigentlich und das tlw. gar nicht. ;-)
Nichts ist perfekt und wenn ich mich nicht irre, gibt es auch Ausfälle,
die smart nicht erkennt. (Meine da stand mal was in einer der Linux-
Zeitschriften.)
Eigentlich. In der Praxis ist SMART sowas von unzuverlässig - da kann man gleich eine Münze werfen.
Dem kann ich nur zustimmen. Ich kenne einige klar defekte Festplatten, die von Smart noch als OK bezeichnet werden. Da fragt man sich schon, was das Ganze soll, wenn nicht einmal offensichtliche Defekte angezeigt werden. Naja.
Dazu kommt, daß ext3 im falschen Moment unterbrochen, durchaus Unsinn verzapfen kann. Verschlimmernt kommt hinzu, daß bei ext3 per default barrier aus sind - schließlich interessiert kein Schwein, ob die Daten es auf die Platte schadden oder das fs in Ordnung ist - hauptsache Geschwindigkeit!
...
wenn einem an den Daten liegt, nimmt man sowieso lieber reiserfs oder xfs.... die haben barrier an - und sind dann deutlich schneller als ext3, wenn man das dort auch aktiviert.
Das ist doch genau, was beim Check regelmäßig überprüft wird, zur Datenintegrität kann fschk auch keine Aussagen treffen. Redundant und lästig, jedenfalls habe ich hier noch kein bestechendes Argument gehört, wo der Vorteil der regelmäßigen Checks liegen soll. Mein xfs macht sowas übrigens nicht und ich glaube noch immer, dass man das einfach aus Gewohnheit von ext2 übernommen hat.
Nein, den wie gesagt kann die Datenstruktur auch am Journaling vorbei beschädigt werden.
Mögliche Ursachen die mir spontan einfallen
1. Fehler in der Implementierung des Dateisystems
2. Hardwarefehler der HDD
3. Eine andere Implementierung mountet das Dateisystem und beschädigt es