Fragmentiert ReiserFS begutachtung bitmap.c

hallo,
in vielen benchmarks lese ich , das reiserfs schneller ist wie ext3. nun weiss ich leider nicht, wie reiserfs mit fragmentierung umgeht. in der bitmap.c
http://users.sosdg.org/~qiyong/lxr/source/fs/reiserfs/bitmap.c?v=2.6.16;a=x86_64
steht ja der quellcode für blockallocation drin, aber ich kann kein c, kann das jemand herausfinden?
das passende dateisystem ist nämlich schwirig. ext3 ist zu langsam. xfs benötigt den lilo, wenn sich der kernel verschiebt bootet nix mehr. reiser4 soll toll sein, ist aber bei keiner distri dabei. also bleibt nur reiserfs, welches bei suse ja lange standart war...

Grub unterstützt XFS. ReiserFS eignet sich in der Regel besser für große Dateien. Wer sagt das ext3 langsam ist? Das ist es nämlich nicht und ausserdem kommt es dabei unteranderem auf den Anwendungsfall an.

hi,
unter ubuntu bootete linux nicht mit grub und xfs zusammen.
nun ich habe gelesen, das ext3 recht stark fragmentiert, es arbeitet mit festen inoden und hat keinen b-tree. ausserdem soll der durchsatzz langsamer sein.
deshalb rückt reiser wieder in mein interesse

Welches Ubuntu?

frindly schrieb:

ich habe gelesen, das ext3 recht stark fragmentiert, es arbeitet mit festen inoden und hat keinen b-tree.

Zum Vergrößern anklicken....

Wichtiger ist, wie voll die Platte ist ausserdem ist die Fragmentierung weniger als bei anderen Dateisystemen. Das ext3 stark fragmentiert stimmt so nicht.

Was soll das bitte mit einem Binary- Tree bzw. mit den Inodes zu tun haben? Schon mal daran gedacht, das die Verwendung von einem Binary- Tree in diesem Fall möglicherweise von der Performance schlechter bzw. für den Anwendungsfall evtl. nicht zu gebrauchen ist?

frindly schrieb:

unter ubuntu bootete linux nicht mit grub und xfs zusammen.

Zum Vergrößern anklicken....

IIRC unterstützt GRUB XFS seit ca. 2 Jahren, das wundert mich sehr dass aktuelle Ubunti das nicht können sollen. Selbst wenn dem so wäre: was hindert dich daran Verzeichnisse mit hohem HDD IO (/var /home /srv ...) auf eine XFS Partition auszulagern?

frindly schrieb:

nun ich habe gelesen, das ext3 recht stark fragmentiert, es arbeitet mit festen inoden und hat keinen b-tree. ausserdem soll der durchsatzz langsamer sein. deshalb rückt reiser wieder in mein interesse

Zum Vergrößern anklicken....

Wenn du einen HP Fileserver mit > 100 Nutzern aufsetzen willst lohnt die Beschäftigung mit dem Thema Dateisystem vielleicht. Ansonsten: nimm ext3 und gut ist.

xfs bootet nicht mit Grub? ich nehme an in der initrd hast du schon das xfs-Modul drin und es geht trotzdem nicht. Dann genaue Ausgabe von '''grub-install''' posten, aber vorher erst prüfen ob in Verezichnis '''/boot/grub''' und bei Suse währe es '''/usr/lib/grub''' die Datei '''xfs_stage1_5''' existiert, wenn nicht dann ist eine alte Grubversion drauf, wenn sie nur unter /boot/grub fehlen sollte, dann dort hin kopieren.

die Problematik mit der Fragmentierung und den Filesystemtypen haben wir ja hier schon hunderte Mal durchgekaut, also dann eben noch einmal, und jetzt mal richtig ausführlich obwohl 20 Links dazu hier im Forum sicher schneller gehen würden.

frindly schrieb:

nun ich habe gelesen, das ext3 recht stark fragmentiert, es arbeitet mit festen inoden und hat keinen b-tree. ausserdem soll der durchsatzz langsamer sein.

Zum Vergrößern anklicken....

Gibts die Quelle online?
Stark fragmentiert? klar werden große Dateien nicht in voller Länge unmittelbar hintereinander geschrieben, geht auch gar nicht, da Verwaltungsblöcke vom Filesystem im Weg stehen, ansonsten wird beim Schreiben von Dateien schon sehr peinlich genau darauf geachtet, dass da hinten dran immer noch schön Platz bleibt damit eine Datei am Stück weiterwachsen kann. Ein Teil der Verwaltungsblöcke die die Datensequenz bei ext3 bei langen Files jedoch unterbrechen sind genau zu dieser Datei gehörende Verweisblöcke zu den Datenblöcken. Übrigens, sobald der größe zusammenhängende freie Bereich kleiner ist, als die zu schreibende Datei, wird sowieso jedes Filesystem anfangen zu fragmentieren. Fragmentierung wirklich verhindern lassen, würde sich nur durch permanente Defragmentierung was bisweilen unberechnebar das Filesystem extrem belasten würde, nur weil ich eine Datei gelöscht habe, müsste die Halbe Festplatte verschoben werden. Es gibt bei vielen Filesystemen sogar absichtilich immer freie Blöcke zwischen den Files, die läßt ein vernünfiges Filesystem weil, es beim schreiben schon mit der Möglichkeit rechnet, dass sich am Ende der Datei noch was tut, und es beim Beginn des Schreibens ja noch gar nicht wissen kann, wie lang die Datei irgendwann mal wird, Auch das ist Fragmentierung, wenn die Dateien nicht unmittelbar hinter einander stehen. Also gibt es auch bei ext3 Fragmentierung, doch selbst diese ist bei ext2/3 noch längst kein Problem, da die Fragmente groß genug bleiben, das man dabei für eine einzige Datei nicht das ganze Filesystem auslesen müßte. Und selbst wenn die Dateien fragmentiert vorliegen ist das vollkommen Wurst, die lange aneinander gereihte Kette von Datenblöcken die du im Kopf hast, gibt es auf der physikalischen Platte sowieso nicht, da gibt es nur mehrere sich drehende Scheiben mit mehreren Schreib-Leseköpfen auf einem schwenkbaren Kamm, das ähnlich funktioniert wie bei einem Plattenspieler. Ob die Platte überhaupt in der Lage währe die Blöcke so wie sie der Reihe nach logisch durchnummeriert werden an einem einzigen Faden bei einer konstanten Rotationsgeschwindigkeit zu lesen oder schreiben, wollen wir lieber gar nicht erst betrachten, da hier neben bestimmten physikalischen Größen und Geschwindigkeiten auch obendrein noch solche Dinge wie defekt gesetzte und Reserve Blöcke eine Rolle spielen von der nur das Low-Level-Format und die Elektronik der Festplatte eine Ahnung hat.
Doch damit immer noch längst nicht genug, die Platte hat einen Cache, das Filesystem hat einen Cache im Speicher und wie andere Filesysteme auch, hat ext3 ein Journal auf der Platte, (das mal davon ganz abgesehen bei einem echten Anti-Fragmentierungs-Anhänger muss das Journal auf der selben Platte wie das Filesystem ja wohl der absolute Oberhammer sein, weil das muss ja das absolut kontraproduktivste sein was man sich überhaupt vorstellen kann). Ein großer Teil der Dateizugriffe erfolgt durch die Bufferung gar nicht in der Reihenfolge in der die Daten in der Datei stehen sondern in der Reihenfolge der Blöcke wie sie hintereinander auf der Platte stehen, und schon gar nicht immer genau in dem Moment in dem sie geschrieben werden, und oft sind beim lesen einige kleine schon lange im Cache bevor sie das erste mal überhaupt benötigt werden, und Linux weiß das auch und muss nicht erst noch auf der Platte suchen. Beim Schreiben werden dann auch zuerst sich im Cache als unbenutzt vermerkte Blöcke benutzt, und nicht erst 5 Minuten auf der Platte nach feiem Blöcken gesucht. Beim booten von LINUX werden einige 100 oder gar 1000 kleine und kleinste Dateien (oftmals sogar mehrmals) aber auch einige größere Dateien benötigt. Wenn Linux da jede einzelne Dateien, jedes einzelne Verzeichnis, bei jedem lesen immer und immer wieder neu von der Platte laden wollte und das auch noch jedesmal und genau in der Reihenfolge in der sie benötigt würden, dann könntest du am Montag den Rechner anschalten, damit du am Freitag damit arbeiten kannst.
Also das Problem mit der Fragmentierung kommt wo anders her, das kannst du für den Rest deines Linuxlebens als schlechte Erfahrung in die Vergessenskiste legen.

arbeitet mit festen inoden und hat keinen b-tree

Zum Vergrößern anklicken....

was ist da denn so schlecht an dem Prinzip. Uns Deutschen sollte das nicht ganz unbekannt vorkommen, mehrere Stapel vorbereiteter Karteikarten an genau definierten Ort hinterlegt. Kommt ein neues Paket, dann geh ich zu einem bestimmten Stabel und suche von oben nach unten und die erste freie Karteikarte vom Stapel, schreib die Regalnummer und die genaue Position und die Paketnummer drauf, und leg die Karte wieder an genau ihrem Ort an genau ihre alten Position innerhalb des Stapel wieder ab.
Klar könnte es passieren, die Regale sind noch lange nicht voll aber es sind keine Karteikarten mehr da, oder die Regale sind voll und ich hab noch 1000 leere Karteikarten die jetzt gar nicht gebraucht werden. Wenn du dann ein Paket suchst, dann musst du eben diesen ganz bestimmten Stapel Karteikarten ermitteln, und diesen dann aufsuchen, und dort von oben nach unten zählen bis die Karteikarte kommt, auf der das Regal von dem Paket draufsteht.

Die andere Möglichkeit ist eben, du schneidest jedesmal von einer großen Papierrolle einen neuen Zettel ab, und füllst ihn aus mit den Daten deines Paketes, abgelegt wird jetzt auf einen einzigen Stapel von Karteikarten, und zwar musst du jetzt deine Karteikarte genau an eine ganz bestimmte Position innerhalb des Stabels einorden. Du hast zu jeder Zeit immer genau so viele Karteikarten wie Pakete im Regal, wenn nicht, dann hast du ein großes Problem. Suchst du jetzt eine bestimmtes Paket, dann durchsuchst du den einen Stapel Karteikarten, und zwar fängst du in der Mitte an und schaust was steh hier für eine Nummer drauf, ist die größer oder kleiner wie das was sich suche. Kleiner, also suchst du in der oberen Häfte des Stapels wieder in der Mitte weiter, größer oder Kleiner, bis du deine Karteikarte gefunden hast. Hier hast du aber jetzt einen Vorteil, wenn dein Paket nur ein Brief ist, dann schreibst du nur die Lagernummer drauf und sortierst ihn anstelle der Karteikarte in den Stapel ein. Das kann dir schon gelegentlich etwas Zeit sparen beim auffinden von Briefen und Postkarten, jedoch wenn der Stapel mal vom Tisch fallen sollte, und du eine Inventur machen musst? Viel Spaß.

ausserdem soll der durchsatzz langsamer sein

Zum Vergrößern anklicken....

von was reden wir hier für Dateien, sind es große, ganz große, kleine oder ganz kleine, sind es 1000 oder 700000000 sind sie in 5 oder 50000 Verzeichnissen, wie groß sind deine Filesysteme 5GB oder 5TB, sind alle Dateien gleich groß, oder kunterbunt gemischt, werden sie einmal geschrieben und einmal gelesen, werden die Dateien nachdem sich gespeichert sind verändert, wenn ja wo, irgendwo oder nur am Ende oder wird immer wieder hinten dran geschrieben. Werden sie alle 5 Minuten geschreiben und meist nie gelesen. Werden sie immer von vorne nach hinten gelesen oder in bestimmten Reihenfolgen gebraucht, oder werden sie von mehreren Prozessen immer gleichzeitig geöffnet, wenn ja sind dann welche mit Schreibrecht dabei. Um was für Dateitypen handelt es sich, sprich wie schnell könnte dein Rechner überhaupt so eine Datei erstellen ändern oder verarbeiten, oder werden die Dateien nur von wo anders her kopiert, wie schnell sind denn dann deine Datenverbindungen. Und wie schnell sind deine Platten und die Verbindungen zu deinen Platten, wie viel Speicher kannst du deinem Filesystem als Cache zur Verfügung stellen.

Wenn deine Festplatten ständig mindestens 50 % Auslastung haben und du auf all diese und noch mehr Fragen eine genaue Antwort hast, dann kannst du genau für diesen einen speziellen Fall, 2 oder mehr Filesysteme miteinander im Datendurchsatz genau vergleichen. Aber hüte dich davor, sowas dann verallgemeinern zu wollen.

robi

Hallo,

von reiserfs halte ich mittlerweile einen respektvollen Abstand. Bei mir haben sich schon zwei mit reiserfs formatierte Partitionen in Wohlgefallen aufgelöst. Einmal spontan die / Partition. Den Grund konnte ich nicht mehr ermitteln, weil mit der Partition auch die Logfiles hinüber waren. Ein paar Monate später die /home Partition während der Installation von OpenSuse 11.0. Yast hatte während der Installation angebliche Fehler auf der /home Partition gefunden und eine Reparatur vorgeschlagen. Nach der vermeintlichen Reparatur war sie wirklich kaputt.

Gruß
Georg

P6CNAT schrieb:

Hallo,

von reiserfs halte ich mittlerweile einen respektvollen Abstand. Bei mir haben sich schon zwei mit reiserfs formatierte Partitionen in Wohlgefallen aufgelöst. Einmal spontan die / Partition. Den Grund konnte ich nicht mehr ermitteln, weil mit der Partition auch die Logfiles hinüber waren. Ein paar Monate später die /home Partition während der Installation von OpenSuse 11.0. Yast hatte während der Installation angebliche Fehler auf der /home Partition gefunden und eine Reparatur vorgeschlagen. Nach der vermeintlichen Reparatur war sie wirklich kaputt.

Zum Vergrößern anklicken....

Das liegt nicht unbedingt am Dateisystem, sondern es kann auch ein defekt deiner Festplatte vorliegen. Ohne weiteres geht ein Dateisystem nämlich nicht unbedingt kaputt. An einen Hardwaredefekt sollte man bei so etwas schon denken. Zumindest sollten die Alarmglocken kräftig leuten und die Festplatte mal mit den entsprechenden Diagnosetools (smart, Diagnosetools vom Hersteller) überprüft werden.

Also wenn du das Thema wirklich durchfechten willst, beim formatieren mit dem ext3 (was eigentlich "nur" ein ext2 mit journal ist), kann man die Blöckgröße angeben. Je nach Einsatzzweck (z.B. Optimierung auf Geschwindigkeit oder möglichst wenig Verschnitt), beim reiser glaub ich geht das auch.

Einen Vergleich müsste man also mit den selben Parametern anstellen. Und wie ein Vorposter schon gesagt hat, spielen da viele andere Umstände mit. (Festplattentyp z.B.)

In dem neuen CT Sonderheft steht ein Interessanter "Das ext3-Dateisystem" Artikel zu dem Thema. Und in irgendeiner älteren CT.

[offtopic] Das posting von robi empfehle ich übrigens als Lesestoff für gewisse kaufmännische Führungskräfte zuer Erlangung von Respekt gegenüber technischen Entwicklern (und der Technik allgemein).

nun in dem artikel in der ct steht drin...
das z.b. fragmentierung wohl ein thema ist, weil ext3 immer mit blockgruppen arbeitet und eine lokalität der daten anstrebt, was zusammen mit den verzeichnisinformationen zu fragementierung führen kann.
dazu kommt, das ext3 = ext2 + journal + htree ist.
und ext3 kann die daten aus den verzeichniseinträgen nicht mehr entfenen, wenn die datei gelöscht wurde,
dazu muss der htree neu aufgebaut werden.
wenn also viel erstellt und gelöscht wird, laufen die verzeichniseinträge voll.
reiserfs arbeitet ja nicht mehr mit inoden , deshalb kann man keine grösse angeben.

na ja, reiserfs ist dir wohl nicht mehr auszureden, will dir ja auch niemand ausreden, wesshalb ich mir die Mühe sparen kann hier alles was du zusammengetragen hast, zu versuchen ins richtige Licht zu setzen und zu erklären. Also dann schimpf ich doch mal mit auf ext3 dem ollen Ding da, was auch noch kompatibel zu seinen Vorgängern ist. Wenn das so weitergeht gibts ja nie einen Fortschritt. In ein richtiges Filesystem gehört etwas Modernes, Notfalls wird dann auch schon mal statt der Minor einfach nur die Major Version hochgezählt.

Ich frag mich nur, warum heißt das Inode ähnliche Ding da in Reiserfs eigentlich nicht auch wie in den antiquarischen Filesystemen Inode, so wie in anderen Filesystemen auch, sondern "stat item", steht doch eh fast das selbe drinnen? Na gut ein bisschen weniger schon, aber dafür gibt es da aber auch noch "directory items", "direct items" und "indirect items". Und alle werden sie fein säuberlich genau in dem Moment angelegt in dem sie gebraucht werden, und hinterher einfach fallen lassen. Dadurch könnten sie zwar ein bisschen verstreut werden, aber zumindestens treten sie nicht in geordneten Gruppen auf und belegen nicht schon nach dem Anlegen des Filesystems Platz, so dass man sie womöglich auch noch Gruppenweise alle auf einmal lesen kann, eventuell könnte man da ja auch noch einen Dump davon machen ? Wo bleibt denn da die Geheimhaltung, wenn man solche sensiblen Daten auch noch gezielt sichern kann. Jedenfalls, wenn irgend eine Datei in den Rechner rein will muss sowieso erstmal die ganzen Verwaltungsdaten zu dieser Datei zusammengesucht werden, ob das denn aus einem Dump auch gänge? na ja egal wie sie über der Platte verstreut stehen sie müssen her, anschließend nach linux übersetzt werden. Wie heißt das Ding dann gleich wieder? war das dann nicht auch schon wieder "irgenwas inode" ?

Auf jeden Fall ist es besser und wesentlich sicherer wenn wegen jeder popeligen einzelnen Operation am Filesystem der ganze btree wieder neu ausgerichtet wird, anstatt nur hin und wieder mal im htree etwas aufzuräumen, wer von vorne hinein schon schön und immer aufwendig Ordnung hält, hat beim Suchen Vorteile.

Das mit den Verzeichnisseinträgen im ext3 halte ich allerdings auch für reine Platzverschwendung, wenn doch nun das Verzeichnis sowieso immer mindestend die Blockgröße eines Filesystemblockes groß sein muss und sowieso immer als Ganzes gelesen werden muss, warum geht man denn dann so verschwenderisch mit dem Platz in so einem Verzeichnisfile um. Läßt man doch einfach die gelöschten Dateinamen alle drin, und macht sie nur ungültig. Und das bis das Verzeichnisfile fast ans platzen gerät, wahrscheinlich erst dann räumt man ein bisschen auf, um zu erkennen ob man es vergrößern muss oder nicht. Könnte man ruig mal etwas mehr Ordnung halten und jedesmal die gesamte verlinkte Kette von Dateinamen schön sauber aufräumen, soviel Zeit muss ja wohl sein. Überhaupt wie kann man dort eine verlinkte Liste machen, wo jeder Dateinname gleich mit dem Verweis auf die Inode und wirklich genau in der Länge dort stehen kann, so wie er will. Ordnung muss da hin. an das eine Ende gehören die Verwaltungsdaten in klar definierte Felder an das andere die Dateinamen, schön auf 8 aufgerundet, Platz ist wenn überhaupt nur in der Mitte, wo kommen wir sonst hin. Beim Suchen brauch ich dann nur von hinten nach vorne bis zu Mitte nach den Namen zu suchen, und dann vom Anfang bis zur Mitte nach der Platzierung der Verwaltungsdateien zu zählen.
Allerdings mein ext3 Filesystem verhält sich nach außen irgendwie nicht ganz so, das /tmp Verzeichnis wird täglich mit hunderten Dateien geflutet und ständig müssen sie dort wieder weg, ja ich muss zuweilen auch noch selbst Hand anlegen und dort Dateien löschen, und dennoch wenn ich nachschaue, ist die ganze /tmp Direktoriedatei nur genau einen einzigen Filesystemblock groß. Na ja kommt bestimmt noch das mir das ganze Filesystem wegen dieser ewig unlöschbaren Dateinamen voll läuft, immerhin ist die Blockgröße 4K und was sind da schon ein paar hundert Dateinamen. Und bei nähere Beobachtung musste ich nun auch noch feststellen dass sich da bei dem Verzeichnis auch noch hin und wieder mal der Datenblock ändert. ... dann müsste ja jemand den Inhalt meiner /tmp Verzeichnisdatei auswechseln, hat da etwa jemand mein Rootpasswort geknackt oder wie könnte das sonst .....

Na ja und zu der vorsätzlichen Fragmentierung von ext3 brauch ich ja nun nichts mehr sagen, sagt ja auch die ct, dass die Dateien stur durch Blöcke zusammengehalten werden und die Verzeichnisse auch noch wo ganz anders hingeschrieben werden, und die Position der Inodegruppen steht ja von vorne hinein schon fest. Bei so was bleibt ja Linux gar nichts weiter übrig, als bei jedem Lesen eines Verzeichnisses sich soviel wie nur möglich an gebündelten Informationen zu den genauen Positionen der dazugehörigen Fileblöcke zu merken. Na zum Glück stehen diese Informationen wenigstens alle auf Haufen oder sind haargenau an der richtigen Stelle zwischen die Dateidaten eingebaut. Den Speicher der dadurch allerdings vergeutet wird, könnte man wunderschön auch für einen btree nutzen, wie sieht der denn nun aber auf der Platte aus ?

Alles nicht ganz so ernst zu nehmen

robi