Re: reiser oder ext3 f
Hallo Rainer, hallo Eduard Am Sonntag, 14. Juli 2002 10:54 schrieb Eduard Bloch: einzufangen, finde ich das einfach nur noch widerlich. *plonk* Schön. Was dir nicht passt, brauchst du nicht zu lesen. Meint ihr zwei nicht auch, daß ihr euch ein wenig albern anstellt? Macht mal Frieden, langsam ! -- Gruß Frank -- Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: reiser oder ext3 f
Moin Rainer! Rainer Ellinger schrieb am Wednesday, den 10. July 2002: DOS-Zeiten oft genug, wurde mit einer Boot-Diskette schnell gefixt. Heutzutage startet man Knoppix und installiert LILO neu. Mache einfach: echo -n T | dd of=/dev/hda bs=1 count=1 seek=510 Kein Problem... und schaue, wie weit Du mit lilo kommst - der Erste der 9 Experten. Bootblock erfolgreich neuerstellt und die Kiste bootet in diesem Moment. Bist du sicher, zu diesen Erkenntnissen ohne Alkoholeinfluss gefunden zu haben? Gruss/Regards, Eduard. -- I am Stefan Raab of Borg. You will listen to Wadde Hadde Dudeda. Good songs are futile. -- Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: reiser oder ext3 f
Jens Benecke schrieb: Aber natürlich nicht das magische zentrale Bit. Schliesslich genügt es noch heute, nur ein einziges simples Bit zu ändern und schon ist beim nächsten Neustart für das System die Platte komplett leer. Und welches Bit wäre das? Es ist das lustige Bit 4080 (leider nicht 42 oder 137 - schnief, wäre das rührend gewesen, aber trotzdem nette Zahl) und seine fünfzehn darauf folgenden munteren Kummpanen. Hier darf man dem PC mal wirklich ein X für ein U vormachen, oder besser - wenn's wirklich nur 1 Bit der 16 treffen soll - ein T: echo -n T | dd of=/dev/hda bs=1 count=1 seek=510 und weg ist die Festplatte! fdisk findet keine Partitionen, beim Reboot will das BIOS eine System Disk eingelegt haben... Seit Urzeiten wird ein gültiger Bootblock auf PC-Medien (und somit auch der Festplatten-MBR) daran identifiziert, dass in den letzten beiden Bytes die Werte 55 AA (hex) stehen. Das ist ein Abbild der launigen 01 10 Bitfolge - dem versaillesken Pendant MFM-geschädigter Entwicklerhirne. Eigentlich eine kuriose und lustige Geschichte. Bei heutigen durch- schnittlichen mehreren hundert Millarden Bits auf einer Festplatte kommt es teilweise auf einige wenige Bits an, die auf keinen Fall angefasst werden dürfen, sonst gibt es das ganze System nicht mehr. Ich vermute (oder sollte man sagen befürchte), dass 9 von 10 Experten völlig ratlos vor diesem Problem stehen würden. Insofern ein weiteres Kuriosum, dass eine seit über 20 Jahren existenznotwendige Digital- Archäotype kaum bekannt ist. -- [EMAIL PROTECTED] -- Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: reiser oder ext3 f
Rüdiger Noack schrieb: Leider finde ich im Archiv nicht den Beginn? http://lists.debian.org/debian-user-german/2002/debian-user-german-200206/msg01555.html -- [EMAIL PROTECTED] -- Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: reiser oder ext3 f
Eduard Bloch schrieb: = Blödsinn. Das Ding bootet also nicht, so what... Hatte man zu DOS-Zeiten oft genug, wurde mit einer Boot-Diskette schnell gefixt. Heutzutage startet man Knoppix und installiert LILO neu. Mache einfach: echo -n T | dd of=/dev/hda bs=1 count=1 seek=510 und schaue, wie weit Du mit lilo kommst - der Erste der 9 Experten. -- [EMAIL PROTECTED] -- Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: reiser oder ext3 f
Hi, das klingt nach einer sehr interessanten Diskussion. Leider finde ich im Archiv nicht den Beginn? Könnt ihr mir auf die Sprünge helfen? Gruß Rüdiger __ Gesendet von Yahoo! Mail - http://mail.yahoo.de Yahoo! präsentiert als offizieller Sponsor das Fußball-Highlight des Jahres: - http://www.FIFAworldcup.com -- Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: reiser oder ext3 f
Tach auch! Am Son, den 07 Juli 2002, schrieb Jens Benecke: On Sun, Jul 07, 2002 at 05:14:48PM +0200, Rainer Ellinger wrote: Ich vermute Du möchtest eher Fehler, die der Kernel gar nicht erkennt oder wahrnimmt. Dazu reicht vielleicht schon zufallsgesteuert das eine oder andere Bit auf der Platte zu ändern. Aber natürlich nicht das magische zentrale Bit. Schliesslich genügt es noch heute, nur ein einziges simples Bit zu ändern und schon ist beim nächsten Neustart für das System die Platte komplett leer. Und welches Bit wäre das? Ob es mit einem Bit geht weiß ich nicht, aber ein Byte im MBR bzw. der Erweiterten Partition, das für den Dateisystemtyp zuständig ist, müßte es gehen. Gilt AFAIK aber nicht bei allen Partitionstabellenarten (z.B. bei Apple nicht). Dieter -- Registrierter Linux Benutzer #186360 - GnuPG Key-ID: FDE465C9 Bevorzugt verschluesselte eMails. Nichts ist wie es scheint, alles ist erlaubt! msg12210/pgp0.pgp Description: PGP signature
Re: reiser oder ext3 f
Eduard Bloch schrieb: Der Baum lässt sich besser retten. Die Reiser-Nodes ergeben in sich eine logische Struktur. Das reiserfsck kann ohne jede Vorinformation die ganze Platte Sektor für Sektor scannen und alle Beweise, Watson, Beweise... Um eine solche vollständige Wiederherstellung zu ermöglichen, müsstest du noch mehr Metadaten mitschleppen, d.h. zumindest eine eindeutige ID in jedem Dateiknoten und jedem Extent. Beweise? Ich habe es so gemacht - mir reicht das als Beweis. Es war die von Reiser bekannte kann Datei nicht zugreifen Situation. Und dann bin ich in die gleiche Falle getappt, wie viele andere, und dachte ein fsck kann nicht schaden. Das war zu dieser Zeit die typische ext2 Angewohnheit, die bei Reiser allerdings öfters fatal verlief. Das reiserfsck von Anfang 2001 war grottenschlecht und schrieb ja schon bei reinen read-only Checks Daten auf's Device. Nach einem Check mit dem Hinweis auf nur durch --rebuild-tree fixbar, hatte ich diesen auch gemacht und mit einem Segfault mittendrin war dann der Tree komplett weg. Weitere reiserfsck Durchläufe ergaben ebenfalls Segfaults und verschlimmerten die Sache nur. Ich habe aber 95% der Daten wiederbekommen. Zuerst dachte ich, ich müsste mir das Rettungstools komplett selber schreiben und hatte mich entsprechend mit den Reiser-Internas beschäftigt. Zum Glück wurde das reiserfsck bis Anfang 2002 deutlich besser und lief nach ein paar vorherigen manuellen Eingriffen dann sauber durch. Mit der Option -S benötigt es beim --rebuild-tree keinerlei interne Vorinformationen. Die Tree-Elemente werden an Ihrer Struktur erkannt. Wenn Du Dir die Tree Definitions direkt auf der Homepage von namesys.com anschaust, findest Du dort sehr oft das magische Wort Key oder Previous Key. Im Grunde sind diese Keys schon so eine Art md5 Fingerabdruck. Gibt es an der Previous Position ebenfalls eine Struktur, die nach einem Tree-Node aussieht, bestätigt das die Zuordnung des aktuellen Sektors zum Tree. Der Baum lässt sich so sehr gut wieder zusammenfinden. Alle anderen Elemente (root-Block, Bitmaps, etc.) werden aus den Baum-Informationen abgeleitet, bzw. benötigen keine Vorinformationen. Ich denke, die Situation ist die, dass das reiserfsck mittlerweile ganz brauchbar ist und die Reiser-Struktur eine Art automatisierte Rettung erlaubt, die es bei ext2 nicht gibt, bzw. dort gar nicht möglich ist. Nur interessiert es mittlerweile keinen mehr. Viele hatten Ihr Aha-Erlebnis mit Reiser und haben es schon längst in der Tonne versenkt. Okay, was hast du denn nicht beerdigt? Ich schwanke im Moment zwischen Ext3 und ReiserFS für den demnächst kommenden Server. Ext3 hat im Bekanntenkreis ein Paar Probleme, wenn das Dateisystem Bei Reiser befürchte ich, dass es das Geschmäckle nicht mehr los wird. Wenn schon Reiser selbst vor der Verwendung von Versionen vor 2.4.16 warnt, muss man, das Polemisieren mal bei Seite gelassen, ganz klar sagen, dass die Zeitspanne des No Bad News dann einfach geradezu mickrig ist im Vergleich zu ext2. Man kann Linus sehr dankbar sein, dass er sich immer vehement geweigert hat, diesen oder jenen schicken Mode-Hack zu ext2 aufzunehmen. Bei ext3 stelle ich mir die ketzerische Frage was soll es bringen?. Mir wäre neu, dass es im laufenden Betrieb etwas bringt. Für die nach überlicherweise 6 Monaten oder alle 20-30 Systemboots zwangsweisen fscks braucht man kein neues Filesystem. Es gibt keine technische Begründung für diese Intervalle und sie sind eine reine Geschmackssache. Es spricht nichts dagegen tune2fs -c 0 -i 0 zu benutzen und regelmässige Filesystemchecks zu selbstdefinierten Wartungszeiten durchzuführen. Somit bringt ext3 nur im Fehlerfall etwas, wenn das Filesystem unsauber heruntergefahren wurde. Im professionellen Systembetrieb benötige ich für diesen Fehlerfall aber ebenfalls kein spezielles Filesystem, sondern eine genaue Analyse der Ursache. Ein volles fsck ist dann sowieso Bestandteil der Serviceprozedur. real3m54.676s Wir stellen fest: - Reiserfs ist ungefähr doppelt so schnell beim Durchsuchen, bzw. Ich weiss nicht, ob man time und diese Vorgehensweise als legitimen Benchmark sehen kann. Eher nicht. Aber es steckt meines Erachtens ein Stück wichtiger Wahrheit darin. Man sollte die Benchmarks ignorieren und den Vergleich in der eigenen Umgebung mit dem eigenen Szenario machen. Ich vermute, dass in den meisten Fällen keine signifikanten Unterschiede zwischen ext2, ReiserFS und XFS zu finden sind. Nicht nur bei Messwerten, sondern bei vor allem bei den gefühlten Unterschieden. Wie gesagt, was bleibt denn da noch? XFS kann ich grade nicht testen, JFS fasse ich nicht an (ist lahm auf AIX und hat laut C't zahlreiche Bugs). Ich sehe JFS als reine Kompatibilitätsfunktion, wie UDF oder andere und nicht in der Rolle eines nativen Linux-Filesystems. Die Bug-Darstellung in der c't ist meines Erachtens unqualifiziert und überzogen. Zumal es mittlerweile schon wieder
Re: reiser oder ext3 f
Eduard Bloch [EMAIL PROTECTED] wrote: #include hallo.h Andreas Metzler wrote on Sat Jun 22, 2002 um 06:32:26PM: wenn zu diesem Zeitpunkt auf die Datei darin geschrieben wurde). Aber für Read-Only-Partitionen wohl am besten geeignet (/, /usr). [...] /usr koenntest du auch einfach ro mounten und ext2 verwenden. Hab ich was anderes behauptet? Du kannst heutzutage alles ro mounten, ausser /tmp, /var/tmp, /var/log, /var/run, und /dev per devfs. /etc ist aber muehsam ;-) Du schrubst fuer Read-Only-Partitionen sei ext3 am besten, aber da bringt es doch gar keinen Vorteil gegenueber ext2? cu andreas -- Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: reiser oder ext3 f
Moin Rainer! Rainer Ellinger schrieb am Thursday, den 20. June 2002: Datenstruktur gerissen wird. Ich hatte das bisher nur einmal auf einem olen 486er, ReiserFS konnte _nicht_ repariert werden, die Dateien waren weder lesbar, noch konnte man sie löschen. Der Baum lässt sich besser retten. Die Reiser-Nodes ergeben in sich eine logische Struktur. Das reiserfsck kann ohne jede Vorinformation die ganze Platte Sektor für Sektor scannen und alle Baumelemente daran, dass Sie in's grosse Puzzle passen, ziemlich zuverlässig herausfischen. Beweise, Watson, Beweise... Um eine solche vollständige Wiederherstellung zu ermöglichen, müsstest du noch mehr Metadaten mitschleppen, d.h. zumindest eine eindeutige ID in jedem Dateiknoten und jedem Extent. wichtige Funktionen nur im Source dokumentiert sind (oder waren?). Nach einigen Odyseen mit ReiserFS habe ich es schon vor 1,5 Jahren endgültig Okay, was hast du denn nicht beerdigt? Ich schwanke im Moment zwischen Ext3 und ReiserFS für den demnächst kommenden Server. Ext3 hat im Bekanntenkreis ein Paar Probleme, wenn das Dateisystem vollständig volläuft (gelegentlich zerschossene Verzeichniss-Blöcke, wenn zu diesem Zeitpunkt auf die Datei darin geschrieben wurde). Aber für Read-Only-Partitionen wohl am besten geeignet (/, /usr). Temporäre Daten kommen aufs Reiserfs, bei /var bin ich mir noch nicht sicher. Hat jemand bessere Empfehlung? beerdigt. Die damals entscheidenden Vorteile (tails und journaling) haben sich durch rasant wachsende Hardware-Kapazitäten sowieso erledigt bzw. komplett verlagert. Allerdings. Ich war von den bekannten Benchmarks immer noch nicht überzeugt, und habe etwas praxisnahes simuliert, Schreiben, Lesen, Durchsuchen des /usr-Inhalts. Test mit Reiserfs: Schreiben: real3m54.676s user0m0.520s sys 0m16.630s Lesen: real1m41.925s user0m0.670s sys 0m5.110s Durchsuchen: real0m2.715s user0m0.040s sys 0m0.140s Löschen: real0m7.535s user0m0.070s sys 0m2.560s Reiserfs, notail: Schreiben: real2m58.039s user0m0.440s sys 0m14.890s Lesen: real1m41.882s user0m0.570s sys 0m4.640s Durchsuchen: real0m1.086s user0m0.030s sys 0m0.100s Ditto mit ext2: Schreiben: real3m20.776s user0m0.450s sys 0m9.550s Lesen: real0m29.052s user0m0.520s sys 0m3.880s Durchsuchen: real0m6.703s user0m0.040s sys 0m0.040s Ditto Ext3, defaults: Schreiben: real3m34.107s user0m0.440s sys 0m13.430s Lesen: real0m42.697s user0m0.610s sys 0m3.730s Durchsuchen: real0m6.064s user0m0.050s sys 0m0.100s Löschen: real0m19.503s user0m0.060s sys 0m0.770s Ditto Ext3, data=journal: Schreiben: real3m39.071s user0m0.420s sys 0m14.100s Lesen: real0m43.386s user0m0.620s sys 0m3.830s Durchsuchen: real0m5.985s user0m0.060s sys 0m0.050s Wir stellen fest: - Reiserfs ist ungefähr doppelt so schnell beim Durchsuchen, bzw. ist fast um Grössenordnung schneller wenn mit notail geschrieben wurde - Leseperformance ist dagegen lausig, braucht ungefähr dreifache Zeit (komplexe Datenstrukturen rächen sich, unter Last wird es wohl noch langsamer). Keine Verbesserung durch notail - Schreiben ist etwas langsamer als Ext2/3, aber etwas schneller mit notail. - Reiserfs mit notail ist richtig fix beim Durchsuchen. - Ext3 schreibt ca. 10% langsamer als Ext2, und liest ca. 30% langsamer - Daten-Journaling kostet nur ein Paar Prozent der Schreib-Performance Directoryeinträge hunderter einzelne Dateien mit völlig zufälligen Werten gefüllt wurden. Das war der Moment, wo ich ext3 (eine Revision vor der Integration in den Mainline Kernel) bereits beerdigt hatte. Fasse ich auch nicht mehr. Wie gesagt, was bleibt denn da noch? XFS kann ich grade nicht testen, JFS fasse ich nicht an (ist lahm auf AIX und hat laut C't zahlreiche Bugs). Datensicherheit eigentlich müssig. Verfügbarkeit löst man mit Fail-/Takeover Konzepten, oder wie in obigen Fall mit einer USV. Datensicherheit mit Backup. Beides keine Aufgaben eines heutigen Dateisystems. Ja. Und die Gefahrenminierung mache ich bald durch mounten aller Dateisysteme read-only, ausser /var. Du bist Dir sicher zu wissen, wie sich ext3/2 intern unterscheiden? Ich denke schon... # grep-available Bloch | grep Packa.*ext3 Package: kernel-patch-ext3-2.2 Package: kernel-patch-ext3-2.4 Package: kernel-headers-2.2.20-udma100-ext3 Package: kernel-image-2.2.20-udma100-ext3 ext3 ist strukturell identisch zu ext2. ext3 hat nur noch einen organisatorischen Vorschalt-Aufsatz, der das Risiko verlagert. Weniger kleine, belanglose Probleme und diese auch weniger oft, dafür höheres Verlustrisiko bei kapitalen Ereignissen. Soso, was für kapitale Ereignisse sollen das sein? Ich suche immer noch nach einer Möglichkeit, im laufenden Betrieb IO-Fehler zu faken, um ein Paar realistische Tests zu
Re: reiser oder ext3 f
Eduard Bloch [EMAIL PROTECTED] wrote: [...] Ext3 hat im Bekanntenkreis ein Paar Probleme, wenn das Dateisystem vollständig volläuft (gelegentlich zerschossene Verzeichniss-Blöcke, wenn zu diesem Zeitpunkt auf die Datei darin geschrieben wurde). Aber für Read-Only-Partitionen wohl am besten geeignet (/, /usr). [...] /usr koenntest du auch einfach ro mounten und ext2 verwenden. cu andreas -- Unofficial _Debian-packages_ of latest _tin_ http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/ -- Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: reiser oder ext3 f
#include hallo.h Andreas Metzler wrote on Sat Jun 22, 2002 um 06:32:26PM: wenn zu diesem Zeitpunkt auf die Datei darin geschrieben wurde). Aber für Read-Only-Partitionen wohl am besten geeignet (/, /usr). [...] /usr koenntest du auch einfach ro mounten und ext2 verwenden. Hab ich was anderes behauptet? Du kannst heutzutage alles ro mounten, ausser /tmp, /var/tmp, /var/log, /var/run, und /dev per devfs. Gruss/Regards, Eduard. -- Live from d.c.o.u.l.m: Tretkowski's Law: Was Google nicht kennt, existiert nicht. Hmm, du hast soeben die Welt sehr sehr eingeschränkt. Glücklicherweise sind uns die ganzen Massenmörder, Dikatoren, Verrückte, Politiker und Frontpage-User erhalten geblieben. -- Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: reiser oder ext3 f
Tach auch! Am Sam, den 22 Juni 2002, schrieb Jens Benecke: On Sat, Jun 22, 2002 at 08:56:49PM +0200, Eduard Bloch wrote: Hab ich was anderes behauptet? Du kannst heutzutage alles ro mounten, ausser /tmp, /var/tmp, /var/log, /var/run, und /dev per devfs. Fuer /tmp kann man auch tmpfs nehmen. Was ist mit z.B. /etc/mtab? SymLink auf /proc/mounts. Und /home wuerde ich nicht ro mounten. Dieter -- Registrierter Linux Benutzer #186360 - GnuPG Key-ID: FDE465C9 Bevorzugt verschluesselte eMails. Nichts ist wie es scheint, alles ist erlaubt! msg11013/pgp0.pgp Description: PGP signature
Re: reiser oder ext3 f
Moin Jens! Jens Benecke schrieb am Wednesday, den 19. June 2002: Das kommt drauf an. Vergiss nicht, das ReiserFS eher zusammengehackt wurde, Das ist IMHO höchst subjektiv, oder hast du den Code komplett gelesen, verstanden und kannst diese Aussage daher treffen? Natürlich nicht. Aber wenn ich mir die Entstehungsgeschichte betrachte, hab ich ein lausiges Gefühl. Zugegeben, ich hatte über einen Jahr lang meine $HOMEs auf ReiserFS, ohne nennenswerte Probleme. Ein Versuch der Eerstellung von /var scheiterte aber daran, dass der Kernel (einer der ersten 2.4.er) das neue FS nicht erkennen wollte, obwohl die reiserfsprogs aktuelle waren und sonst keine erkennbaren Probleme existierten. Der Punkt ist viel mehr (aus meiner Sicht, ich bin relativ früh zum Basteln bei ReiserFS eingestiegen, auf Produktivsystemen aber erst seit 2.4.1x), daß ReiserFS halt viele Annahmen, die die Kernelentwickler für Dateisysteme gemacht haben und viele extN-spezifischen Sachen über den Haufen geworfen hat, und daher anfangs nicht gut funktionierte. Dem stimme ich zu, ich habe mich schon immer gewundert, wieso sich der Wechsel eines Dateisystems so problematisch auf andere Treiber auswirkt, z.B. Ärger mit Samba, mit Quotas usw. (nun ja, die haben im Zuge der Umstellung eine überholte API bekommen). DIE GLEICHEN PROBLEME hatten aber XFS, IBMs JFS usw. auch! Nur hat IBM die frühen Versionen überhaupt nicht veröffentlicht, und somit wusste JFS ist immer noch ein Problemkind. XFS erfodert massive Änderungen an anderen Teilen des Kernels. Auch die Reparaturwerkzeuge sind nicht wirklich zuverlässig. Du möchtest nicht wirklich wissen, was e2fsck in den Anfangsstadien gemacht hat. Rate mal, woher der a core dumping fsck tends to make me nervous Spruch von Linus kommt. ReiserFS gabs damals noch nicht. Toll, mit dieser Aussage implizierst du, dass reiserfs-tools auf dem Stand der ext2progs von 1995 sind. Die momentan verfügbaren Reparaturwerkzeuge sind in meiner Erfahrung (und aus Mitlesen der Mailingliste) genauso gut oder schlecht wie die von extN. Wie gesagt, das will ich gerade anzweifeln. Wenn bei ExtN ein Block nicht mehr lesbar ist, dann trifft es entweder einen Datenblock oder Inode-Block. Das schlimmste, was mir danach passiert ist, war ein Verlust von Dateinamen oder verfälschung des Dateiinhalts (bei IO-corruption). Und jetzt möchte ich ReiserFS sehen, das vollständig auf tolle Bäume vertraut, wie es sich verhalten wird, wenn da ein Stück aus der Datenstruktur gerissen wird. Ich hatte das bisher nur einmal auf einem olen 486er, ReiserFS konnte _nicht_ repariert werden, die Dateien waren weder lesbar, noch konnte man sie löschen. Dir-Index macht etwas anderes. Auf Balancierung wird verzichtet, stattdessen werden Mehrweg-Suchbäume mit grossen Knoten genommen, u.. ..teien Nachteile: Baumhöhe nicht mehr garantierbar. Eine gute Wir werden sehen. :-) Ich sehe das dir-index-ext2 momentan wie Windows ME: Eine erweiterung einer Erweiterung eines Updates eines Patches eines sehr alten Systems. Ja, und es hat seine Nachteile, vor allem noch grössere Platzverschwendung. Vorteile sind, wie gesagt, die Kompatibilität und Rückgriff auf vorhandene Tools. die anderen sind keine Grössen mehr. LycosEurope hat angeblich mehrere -zig TB Daten auf ReiserFS. Mag sein, aber die müssen das Zeug auch sichern. Was macht ein Heimanwender, ohne Backup und so? Wie auch immer, man hört immer wieder über Probleme mit ReiserFS, kaputte Dateien, vermeintliche IO-Errors, Korruption der Baumstruktur. Ich will nicht behaupten, dass die Hardware dabei 100%ig einwandfrei funktioniert hat, trotzdem ist der Schaden von IO-Fehlern bei ExtN erfahrungsgemäss gering. Ich hatte noch mp3.com und sehr viele cache appliance Hersteller vergessen, die finanzieren ihn auch. SuSE unterhält glaub ich auch einen oder zwei fulltime ReiserFS Entwickler. Ohja, diese Sponsoren spammen dann bei jedem System-Start... An Xu's stelle würde ich die Werbung aus dem Source herausoperieren. Reiserfs' fast journaling ist schön, aber was nützt das, wenn die Inhalte nicht mehr konsistent sind? Nichts. Und? Hatte ich noch nicht. Und ich administriere gelegentlich LAN-Party-Server, da gibt es anfangs öfter als einmal am Tag Stromausfälle oder ähnlichen Mist. Ohja, immer wieder lustig... ext2 hat mir nach solchen fällen mehrfach Dateien in /usr/bin o.ä., die niemals beschrieben wurden, mit I/O error bemängelt, die sich nur durch mehrfaches fsck und Neueinspielen der Dateien beheben liessen. Das ist kein Vergleich, nimm ext3 als Referenz. ReiserFS hat (auf der gleichen Hardware) auf dem Event mit 120GB FTP-Server gespielt, war bei den ersten Stromausfällen mit Abstand als erstes wieder oben und hat kein einziges Problem gezeigt. Und was garantiert dir, das die Dateien hinterher konsistent waren? Ich meine damit vor allem geschriebene Daten. Ich bin nach meinen Erfahrungen gegangen, und da hat sich ReiserFS bisher als
Re: reiser oder ext3 f
Hallo Eduard, Eduard Bloch writes: Ich für meinen Teil warte gespannt auf die Portierung des Dir-Index-Patches auf ext3. Jetzt, da ich davon hör, bin ich auch drauf gespannt! Hast Du da einen Link mit dem Status? Viele Grüße, Christoph -- Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: reiser oder ext3 f
On Tue, 18 Jun 2002 08:07:06 +0200 Kristian Rink [EMAIL PROTECTED] wrote: [reiserfs] Ich habe bei mir festgestellt, dass reiserfs erheblich höhere CPU-Last verursacht. Bei kleinen Dateien mag es zwar effizienter sein, aber bei wenigen, grossen Dateien ist es wesentlich langsamer. Auf einem P166 hatte ich mit einem Soft-Raid5 und ReiserFS gerade mal 3-4MB Durchsatz, weil sonst alles zu war. Das selbe Szenario mit ext3 hatte den doppelten Durchsatz. DMA war übrigens aktiviert. Bei schnellen System 1GHz spielt das bestimmt keine Rolle, aber wer hat schon sowas als FileServer? Gruß Christian -- Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: reiser oder ext3 f
On Tue, Jun 18, 2002 at 07:56:01PM +0200, Christian Zoellin wrote: [reiserfs] Ich habe bei mir festgestellt, dass reiserfs erheblich höhere CPU-Last verursacht. Bei kleinen Dateien mag es zwar effizienter sein, aber bei wenigen, grossen Dateien ist es wesentlich langsamer. Auf einem P166 hatte ich mit einem Soft-Raid5 und ReiserFS gerade mal 3-4MB Durchsatz, weil sonst alles zu war. Das selbe Szenario mit ext3 hatte den doppelten Durchsatz. DMA war übrigens aktiviert. Bei schnellen System 1GHz spielt das bestimmt keine Rolle, aber wer hat schon sowas als FileServer? Die Diskussion läuft alle naselang in der reiserfs- Mailingliste. Ja, ReiserFS benötigt mehr CPU-Zeit als ext2, genauso wie ext2 mehr CPU benötigt als FAT. Es ist einfach ein viel komplexeres Dateisystem. Bäume und das tree balancing usw. brauchen mehr CPU als simple flache Listen (skalieren dafür aber auch mit O(log n) statt O(n)). Suballocation (ist übrigens abschaltbar, mount -o notail) benötigt wieder CPU-Zeit, spart dafür bei kleinen Dateien viel Platz auf der Platte. Dazu kommt noch, daß sich CPU-Geschwindigkeiten um mehrere Größenordnungen schneller vergrößern (und demnach billiger sind) als Plattengeschwindigkeiten. Überleg mal: Deine 1GB Platte von 1995 hatte vielleicht 3MB/sec. Die 80G Platte von heute hat 30MB/sec, Faktor 10. Dagegen hat sich die Geschwindigkeit deines Prozessors vom 1995 üblichen 486-DX4-100 bis P60 (für 500.- DM), auf den heute üblichen P4-1.8GHz (für weniger Geld) mehr als verzweihundertfacht (die ganzen zusätzlichen Funktionen der CPUs, wie Cachegrößen usw noch nicht einmal berücksichtig). Ergo, lieber ein CPU-intensives Dateisystem als ein plattenintensives, und bei Plattenzugriffen spart ReiserFS hier merkbar ein, vor allem wenns um kleine Dateien geht (und ein Linux-System besteht nun mal aus vielen kleinen Dateien, man denke an News-Spools, Maildirs, Squid-Caches, /etc usw.). Fazit, extN (n=2,3,...) ist für schmale Systeme wohl sinnvoller, ReiserFS skaliert besser, wenn die Ressourcen passen. So war es auch gedacht - Google, Yahoo, LycosEurope, usw. sind alles Großkunden von Hans Reiser. -- mfg, Jens Benecke /// www.hitchhikers.de, www.linuxfaq.de, www.linux.ms This mail is an attachment? Read http://www.jensbenecke.de/misc/outlook.html V: Epson Stylus Color 600, 1440dpi, inkl. 4F+4SW-Patronen V: 24x Pioneer SCSI-CDROM, ohne Frontklappe V: 8/40x TEAC SCSI CD-Writer, kann Überlänge msg10810/pgp0.pgp Description: PGP signature
Re: reiser oder ext3 f
Moin Jens! Jens Benecke schrieb am Wednesday, den 19. June 2002: Fazit, extN (n=2,3,...) ist für schmale Systeme wohl sinnvoller, ReiserFS skaliert besser, wenn die Ressourcen passen. So war es auch Das kommt drauf an. Vergiss nicht, das ReiserFS eher zusammengehackt wurde, und üble Portierbarkeit-Probleme hatte. Auch die Reparaturwerkzeuge sind nicht wirklich zuverlässig. Ich für meinen Teil warte gespannt auf die Portierung des Dir-Index-Patches auf ext3. ReiserFS verwendet meineswissens B-Bäume mit variablen Knotenaufbau für Verzeichnisse und Hashing für Dateilisten und Extents. Dir-Index macht etwas anderes. Auf Balancierung wird verzichtet, stattdessen werden Mehrweg-Suchbäume mit grossen Knoten genommen, und innerhalb der Knoten mit einer ausgetüftelten Hash-Funktion adressiert. Vorteile: noch schnelleres Hinzufügen und Löschen von Dateien Nachteile: Baumhöhe nicht mehr garantierbar. Eine gute Hash-Funktion macht aber die Wahrscheinlichkeit von ausgearteten Fällen gering. gedacht - Google, Yahoo, LycosEurope, usw. sind alles Großkunden von Hans Reiser. Für Google möchte ich eine Bestätigung sehen, die anderen sind keine Grössen mehr. Was ist mit Journalling für Daten (was Ext3 u.a. kann)? Reiserfs' fast journaling ist schön, aber was nützt das, wenn die Inhalte nicht mehr konsistent sind? Gruss/Regards, Eduard. -- As of next week, passwords will be entered in Morse code. Frank Knappe in debian-user-de -- Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
