Re(6): 60 tage disc check
Geizhals » Forum » Linux-Support » 60 tage disc check (22 Beiträge, 930 Mal gelesen) Top-100 | Fresh-100
Du bist nicht angemeldet. [ Login/Registrieren ]
.  Re: 60 tage disc check  (Raydoo am 10.01.2006, 15:24:33)
..  Re(2): 60 tage disc check  (-"Dave"- am 10.01.2006, 15:28:26)
...  Re(3): 60 tage disc check  (Raydoo am 10.01.2006, 15:33:39)
...  Re(3): 60 tage disc check  (sharky2 am 10.01.2006, 18:51:47)
.  Re: 60 tage disc check  (hariw am 10.01.2006, 15:29:37)
...  Re(3): 60 tage disc check  (Robe am 11.01.2006, 17:21:10)
.....  Re(5): 60 tage disc check  (Robe am 13.01.2006, 16:37:41)
......
Re(6): 60 tage disc check
13.01.2006, 23:19:44
Nochmal...

Reiserfs hat kein Problem bei Stromausfällen. Das Dateisystem bleibt konsistent. Das bedeutet natürlich nicht, daß die Daten in den Files selbst in Ordnung sein müssen...

Nur hast du eben bei einem defekten File weitaus weniger Schaden als bei einem defekten Filesystem. In den einem Fall reicht es, das defekte File zu recovern (und ich denke nicht, daß es heute noch einen einzigen gibt, der keine Backups macht) - in dem anderen Fall solltest eh gleich das Dateisystem selbst neu anlegen.

Wenn ext3 übrigens verläßlich Daten halten würde, bräuchtest kein e2fsck mehr... Mir ist schon klar, daß die Aufbausemantik dieselbe ist - mir ist auch klar, daß daher implizit der Teil in den Superblocks weiterhin ein Checkpoint-Intervall kennt - allerdings vermutete ich, daß das andere Gründe hat. Das einzige, was ja wirklich für ext3 im vergleich zu anderen Journalling Dateisystemen (egal ob reiser, xfs, jfs2) spricht ist IMHO, daß man es bequem in ext2 zurückwandeln kann... Und dann braucht das als ext3 angelegte, dann als ext2 verwendete Dateisystem natürlich wieder das Check-Intervall. Wenn ext3 funktionieren würde wie versprochen, müßtest mir erst den Sinn eines e2fsck erklären ;-)

Tatsächlich wollten wir (zur Zeit der 2.4.19er-Kernel) auf unseren Servern ext3 verwenden - weil wir ihm mehr zutrauten als reiser - weil es eben auf einer soliden Basis aufsetzten. Es stellte sich allerdings durch selbstgeschriebene testprogramme [die massivst und seehr parallel im Dazeisystem werkten] bald heraus, daß es durch script nur durch Standard-operationen (Directories anlegen, mit einem Prozeß offenhalten, durch andere Prozesse das dir löschen und darin wieder rekursiv dirs anlegen, ... ) reproduzierbar war, daß der Server bei ext3 einfror... komplett. Bei reiser 100% CPU-Last - aber stabil.

Ein wichtiger Punkt ist noch, wann eigentlich ein reiserfsck notwendig sein sollte. Tatsächlich hast du - nach meiner Erfahrung - eine rund 10%ige Chance, daß es nachher komplett hin ist. Allerdings braucht man eben kein reiserfsck nach einem Stromnausfall - da bleibt es eh konsistent. Ich brauchte es nur nach einem Festplattenausfall im Raid0 - wenn ich noch versuchen wollte, etwas zu retten....

Und wenn du beinhart behauptest, daß ext2 eh super sei - und damit den Sinn von Journallenden Dateisystemen nicht anerkennst - dann laß ich den Thread hier. Es ist deine persönliche Überzeugung, die halt nicht sonderlich viel mit Produktionsumgebungs-Empfehlungen zu tun hat. Was aber nicht verwundert, da du ja bewußt verfremdete Threads zitierst oder auch mal schnell eine Thread-Reply mit "zealot", .. eröffnest.

EDIT:
Gründe gegen ext3:
Nicht online resizable... Sogar für ein vergrößern muß man das Blockdevice unmounten. Damit ist es unbrauchbar für jeden normalen Rechner, in dem man LV's für /, /usr, ... anlegt
Abstürze - getestet bei 2.4.19. Keine Ahnung, ob sich der ext3-Source stark modifizierte seitdem.
Nicht einmal die Entwickler selbst vertrauen ext3 - denn sonst hätten's net extra e2fsck implementiert - denn dessen eingeleitete Operationen müssen sich ja wohl wieder im journal abspielen, also war es sicher auch Aufwand für die Entwickler.

Gründe pro ext3:
Läßt sich als ext2 "reusen"
Kann in einem langsamen Modus auch die Daten- und nicht nur die Dateisystem-integrität sicherstellen
Hat das immutable-Bit implementiert
Mehrere Blockgrößen möglich.

Sowohl die Abstürze als auch das nicht-online-resizeable machen für mich das Dateisystem unempfehlenswert. Da lebe ich lieber mit reiser, dessen reiserfsck Probleme verursachen kann - da man es eh nie braucht.

13.01.2006, 23:28 Uhr - Editiert von gepeinigter_aon_neukunde, alte Version: hier
Antworten PM Alle Chronologisch Zum Vorgänger
 
Melden nicht möglich
.......  Re(7): 60 tage disc check  (Robe am 15.01.2006, 18:31:20)
.........  Re(9): 60 tage disc check  (Robe am 15.01.2006, 21:37:32)
..  Re(2): 60 tage disc check  (-"Dave"- am 10.01.2006, 15:36:52)
 

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung