Diskussion:Ext3/Archiv

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:Ext3/Archiv#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:Ext3/Archiv#Thema_1

Maximale Anzahl an Verzeichniss/Unterverz.einträgen

Gibts da irgendwelche offiziellen werte? Ich habe gerade mal rumgespielt, das Max. von Unterverzeinissen in einem Verz. sind 32k Wäre vielleicht mal ganz nett das auch aufzulisten. Manche FS unterscheiden sich hier doch recht deutlich.

Ist das wirklich wichtig? Also in welchem Falle kommen denn mehr als 32.000 Unterverzeichnisse zustande? Aus meiner Sicht ist diese Angabe unrelevant da praxisfern. Nagut, wer es braucht und meint, es müsse unbedingt im Wiki stehen, aber ich persönlich halte diese Information für entbehrlich und unnötig.

Ja, das ist es - FAT und NTFS unterstützen beispielsweise nur eine bestimmte Anzahl von Zeichen im gesamten Pfad inkl. Dateinamen und Erweiterung. Überlange Pfade können zwar etwa per Firefox und so manchem Download-Addon erzeugt (und gekürzt), aber entsprechend abgelegte Dateien nicht geöffnet oder angezeigt werden. Da sind zwar noch immer mehr erlaubte Zeichen als über einen Samba-Netzwerkzugriff möglich, aber wie sieht es denn hier bei ext3 aus? --87.168.51.241 12:58, 16. Feb. 2009 (CET)

sittliche Dateisysteme?

[...entwickelte Journalingerweiterung für ext2 sorggt dafür, dass Metadaten nicht mehr korrumpiert werden können...]

Korrumpiert heißt laut Langenscheid-Fremdsprachenbuch moralisch oder sittlich verdorben, kann es sein, dass es korrupt lauten sollte, also falsch übersetzt wurde?

im Lateinischen ist corruptus die Perfektform zu corrumpere, man kann also sagen, dass korrumpieren das adäquate Verb zum Adjektiv korrupt ist. Da jedoch korrupt eine Bedeutungserweiterung vom moralischen auf, wie ja hier ersichtlich, den technischen Sektor erfahren hat, lässt sich diese Erweiterung eigentlich auch auf "korrumpieren" übertragen...Da wir jedoch ne deutsche Wikipedia sind und keine lateinische, und es sich außerdem schöner liest, bin ich dafür, das anders auszudrücken... (bloß wie???)Hoffentlich hab ich mich da noch richtig an meine schon etwas länger zurückliegenden Lateinstunden erinnert...MfG, Nasenatmer 13:27, 15. Okt 2005 (CEST)

Ich hab das mal in "beschädigt" geändert, da der englische Begriff "corrupted" sicher nur ungenügend mit "korrumpiert" übersetzt wurde. HorstHorst 16:05, 20. Apr 2006 (CEST)

Vorteil <-> Nachteil

Eines der Hauptkritikpunkte bei ext3 ist die Tatsache, dass es die Block-Pointer der Inodes mit Nullen überschreibt. Dies macht ein Wiederherstellen von Dateien nach einem Löschvorgang nahezu unmöglich, was ein deutlicher Nachteil gegenüber anderen Dateisystemen darstellt.

Könnte man auch als Vorteil ansehen. --Kloth 02:06, 18. Dez 2005 (CET)

In wie fern? Falls du auf den Teil der Datensicherung schielst, bei der das vernichten von Daten im Vordergrund steht, dann ist es kein Vorteil, weil diese Art von Datenvernichtung die Daten selbts nicht vernichtet, und mit geeigneten Methoden auslesbar ist. Es ist dann nur schwierig, die Dateien wieder herzustellen, die Daten ansich sind aber noch da. --Liquidat, ^Diskussion, 07:44, 18. Dez 2005 (CET)

Es geht dabei nicht darum, wie einfach eine Wiederherstellung absichtlich oder unabsichtlich gelöschter Daten möglich ist. Durch das Nullen von gelöschten Einträgen wird es erheblich vereinfacht, Inkonsistenzen im Dateisystem bei echten Katastrophenszenarien wie Softwarefehlern oder Hardwareausfall zu beheben, das Löschen von Dateien durch einen Benutzer gehört nicht dazu, für diesen Fall sind Backups zuständig. Ich habe die Passage jetzt etwas umformuliert. --Michael Meier 18:42, 2. Feb. 2007 (CET)

Wo wir bei Vor/Nachteilen sind: Auch dieser Artikel verschweigt mal wieder den (für den Normaluser) immens wichtigen Vorteil des Nicht-Fragmentierens - bzw. der Eigenschaft von ext2/3, daß Fragmentierung nur leicht und vorübergehend auftritt, was man von NTFS ja kaum behaupten kann. Ok niemand will hier Linux-Evangelismus, trotzdem, solch ein Thema muss auch im Wiki behandelt werden! Menschenskind manchmal glaubt man echt ihr steht alle bei Steve Ballmer auf der Gehaltsliste.84.167.71.169 13:35, 16. Mär. 2008 (CET)

Das ist leider Quatsch, ext3 fragmentiert sehr wohl gehörig, nur messen die meisten Linuxuser leider Fragmentierung in Prozent der fragmentierten Dateien - was deshalb reinster Stuss ist, weil auf jedem Linuxsystem tausende von Dateien existieren, die kleiner als ein Block sind - die also gar nicht fragmentieren können. Siehe dazu auch Heise Open: Ext3 tunen Dass man ein modernes Ext3 oder Ext2 mit H-Baum-Verzeichnissen usw. aufgrund des schon lange verstorbenen Defrag-Projektes nicht mehr defragmentieren kann, ist also durchaus ein Nachteil. ;-) --SvenEric 15:27, 5. Dez. 2008 (CET)

Windows Tool zum formatieren

Sollte man vllt n Link zu nem Programm machen das Ext3 unter windows formatieren kann?

Es sind schon zwei Links dabei auf Werkzeuge für Windows, bieten die nicht auch die Funktionalität? So oder so bekomme ich schon bei diesen Links Bauchschmerzen, da sie nicht gerade "das Beste vom Besten" (Wikipedia:Weblinks) darstellen, und nicht mal im Text erwähnt werden. Für so was sind Link-Verzeichnisse da, leider hat dmoz die Kategorie aber noch nicht. --Liquidat, ^Diskussion, 17:31, 29. Nov 2005 (CET)

Schreibweise

Schau ich mir die Weblinks und sonstige Literatur an, stelle ich fest, daß in den 'offiziellen' Dokumenten durchgängig Ext3 (also mit großem E) geschrieben wird, mithin dieses die 'offizielle' Schreibweise ist. Wenns keine ernsthaften Einwände gibt, stelle ich das beizeiten mal um (und entferne die Andere-Schreibweise-Vorlage). Dto. übrigens auch bei Ext2. Grüssle, --Gnu1742 13:50, 24. Feb 2006 (CET)

Die Faq spricht von einem kleinen e, gleiches gilt für die Schreibweise auf der Projetkwebseite und für das Whitepaper von Red Hat. Bitte gib mal ein konkretes Beispiel an für die Großschreibung, damit klarer wird, was du meinst. --Liquidat, ^Diskussion, 03:20, 26. Feb 2006 (CET)

*Tomaten von den Augen nehm* Du hast Recht. Da war ich vermutlich etwas forsch in dieser Aussage. In einem Dokument, das ich letztens vor Augen, hatte stand vermutlich das ext3 häufig am Anfang des Satzes. Allerdings wundert es mich, daß dann anscheinend die Schreibweise beim Übergang von Ext2 auf ext3 geändert wurde, denn was den Vorgänger angeht bleibe ich bei meiner Aussage. --Gnu1742 10:08, 26. Feb 2006 (CET)

Bei ext2 fällt mir auf, dass in der Doku fast immer von "Ext2fs" gesprochen wird, sonst von Ext2. In der manpage aber wird es als ext2 bezeichnet. Änderungen sollten aber bei dem Artikel dort diskutiert werden. --Liquidat, ^Diskussion, 17:39, 26. Feb 2006 (CET)

Jep, deswegen hab ich es dort auch auf der Diskussion stehen, hat sich nur noch niemand diesbzgl. geäußert... --Gnu1742 18:29, 26. Feb 2006 (CET)

Ext2->Ext3 - Ext3->Ext2

Ist es gefahrlos möglich einfach ein Dateisystem statt ext2 in ext3 bzw. umgekehr zu mounten. Oder müssten bei einen solchen Wechsel (bei mir oft nur ausversehen) was beachtet werden. Bis jetzt gab es auf jedenfall noch keinen Datenverlust. 217.245.205.51 23:22, 7. Mär 2006 (CET)

Ein Ext3 als Ext2 zu mounten ist definitv gefahrlos, da wird das Journal ignoriert. In der Gegenrichtung: *schulterzuck* --Gnu1742 07:58, 8. Mär 2006 (CET)

ext3 Erweiterung

Vielleicht sollte man noch erwähnen, dass es jetzt möglich ist mit dem fs eine Platte von 1Ebyte zu verwalten!

(Quelle: http://www.golem.de/0606/45880.html )

Naja, das ist bzw. war bisher nur eine Entwicklerversion und durch Ext4 ist meiner Meinung fraglich, ob sich ein Patch für Ext3, der es zu einem 48b FS macht, jemals durchsetzen wird. --SvenEric 17:22, 5. Dez. 2008 (CET)

ext3 dirindex

Was genau mach der dir-index bei ext3? Sollte sowas nicht im Artikel stehen? --Gruß, Helge 22:13, 6. Okt 2006 (CEST)

Ext3 von Windows aus lesen

Die Weblinks sollten angeben, welche der Treiber open source oder kostenpflichtig sind. -- Simplicius ☺ 16:22, 12. Jan. 2007 (CET) ^

Fragmentierung und Ext3 oder nicht fragmentierend ???

Wie verhält es sich mit Fragmentierung bei Ext3. Spielt die eine Rolle?

Ich habe auch irgend wo mal gehört gehabt das EXT3 nicht fragmentierend ist.

Dem Artikel Fragmentierung (Dateisystem) nach zu urteilen gibt es kein Tool zum Defragmentieren von EXT3, dort wird aber ein Weg zum defragmentieren - über Erstellung einer Tar-Datei des einen Device auf ein anderes Device, löschen der Dateien auf dem Device und Entpacken auf dem Device - beschrieben! Also scheint es doch Fragmentierung in EXT3 zu geben?

Vielleicht könnte jemensch der Ahnung hat, das bitte aufklären.

Fenris81 15:53, 13. Jan. 2009 (CET)

In diesem Bereich halten sich noch immer zahlreiche Mythen und Halbwissen. Ext-Filesysteme würden angeblich nicht fragmentieren oder - noch besser - wären selbstdefragmentierend. Beides ist Unsinn. Auch die Ext-Dateisysteme können fragmentieren und tun dies auch. Allerdings wurde bei der Konzeption Gehirnschmalz investiert, um die Fragmentierung möglichst gering zu halten. Dies etwa im Gegensatz zu FAT, wo die Fragmentierung ein ernstes Problem ist, weshalb Windows-Benutzer seit Jahrzehnten immer brav defragmentieren. Es gibt durchaus auch Defragmentierungswerkzeuge für Ext-Dateisysteme. Ich persönlich hatte noch kein dringendes Bedürfnis, so ein Tool auch zu benutzen. Die Algorithmen im Linux-Kernel gegen Fragmentierung scheinen recht gut zu sein. --Echoray 14:14, 16. Feb. 2009 (CET)

Darüber ist ja auch einiges im Artikel „Das Linux-Dateisystem Ext3 tunen“ auf heise open zu finden[1]. Siehe →Weblinks.

Gruß, ‣Andreas•⚖ 21:37, 16. Feb. 2009 (CET)

Ich möchte mal noch anfügen, was ich gerade erst im Dezember auch als Schlussfolgerung dieses Heise-Artikels in einem anderen Zweig, aber auf dieser selben Diskussionsseite hier, gesagt habe: Ext3 fragmentiert gehörig, der Gehirnschmalz der Entwickler führte auch mehr dazu, dass Daten eng beieinanderliegen, als dass Fragmentierung im Vergleich zu anderen modernen Dateisystemen besonders gut verhindert würde - siehe Ablage der Dateiinhalte möglichst nah beieinander. Einen Vergleich mit FAT anzustellen ist darüberhinaus der größte Schwachsinn überhaupt, da NTFS bisher bei jedem Windows NT Standard gewesen ist und Windows NT ist auch auf Clientsystemen bereits das Standardwindows seit 2001 - seit acht Jahren. Und für aktuelle Versionen von Ext2 und Ext3, das steht ja auch im Heise-Artikel, gibt es eben keine Defragmentiermöglichkeit, auch nicht mit ausgehängtem FS, die nicht die Datensicherheit gefährden würde, weil die aktuelle Version von defrag noch in einer Zeit veröffentlicht wurde, als es viele Sachen, die heute nicht nur Ext3 sondern auch Ext2 ausmachen, wie H-Baum-Verzeichnis-Indizes, noch nicht existierten - Ext3 an sich (Ext mit Journaling) gabs da glaube ich auch noch nicht. --SvenEric 09:35, 4. Apr. 2009 (CEST)

Warum NTFS in einigen Anwendungsfällen stärker fragmentiert als Ext3, ist nicht ganz klar, liegt aber nicht am fehlenden Hirnschmalz der NTFS-Designer, sondern eher möglicherweise an der Besonderheit der MFT. Ich kann mich nur an einen einzigen Test erinnern, der mal Fragmentierung von NTFS und einigen Linuxdateisystemen verglich. Das war mehr ein Kurztest in Linuxforen.de. Und weil man dort nur eingeloggt die Boardsuche benutzen darf, kann ich den jetzt nicht verknüpfen. Aber in dem Test kam raus, dass NTFS ungefähr zehn mal stärker fragmentiert als ReiserFS 3 und Ext3, was jetzt erstmal wahnsinnig viel klingt, es kam aber ebenfalls raus, dass Ext3 und ReiserFS ihrerseits etwa zehn mal stärker als XFS fragmentieren - hat das nun dazu geführt, dass nur noch XFS genutzt wird? Komischerweise nicht. Und NTFS benutzt seit über zehn Jahren Extents bei der Anlage von Dateiinhalten - ein Feature, das Ext erst mit Ext4, das den meisten Linuxgeeks auch jetzt im April 2009 immernoch zu instabil ist, erwerben wird. Ext ist nicht fortschrittlich, es ist nur das Dateisystem mit der größten Verbreitung im Linux-Bereich und deswegen von allen Linuxdateisystemen am stärksten getestet - das und nichts anderes ist sein Vorteil. Und weil die meisten Linuxuser bisher auch nicht mehr brauchen, als irgendein stabiles 32b-Dateisystem, ist es halt auch Standardvoreinstellung der meisten Linuxdistros - nicht weils High-Tech wäre. --SvenEric 09:35, 4. Apr. 2009 (CEST)

P.S.

Warum nun Windows-User ständig defragmentieren? Weil sie es können und an Tuning-Aktionismus leiden. --SvenEric 09:47, 4. Apr. 2009 (CEST)

Und weil von FAT her so gewöhnt sind. Und FAT fragmentiert ja wirklich fürchterlich, oder ist das auch nur so eine Legende? -- Maxus96 21:00, 17. Mai 2009 (CEST)

Kritikpunkte

... sind keine und gehören in die "Technischen Eigenschaften" integriert. -- Maxus96 20:53, 17. Mai 2009 (CEST)

Größe des Dateisystems

im englischen wikipedia Artikel ist die Rede von 2-16 TiB und hier von 2-32 TiB. Was stimmt nun? Warum gibts bei "Größe einer Datei" und "Größe des Dateisystems" eine von bis Angabe? Abhängig von der Architektur? -- 134.93.51.36 11:51, 20. Sep. 2009 (CEST)

Gibt es einen Beleg für die fork Unterstützung?

Weder Google noch dien engl. Wikipedia liefern einen Hinweis darauf, dass ext3 forks oder ADTs unterstützt. Leider wird eine entsprechene Änderung mit irrelevantem Kommentar zurückgenommen. (nicht signierter Beitrag von 217.86.44.96 (Diskussion | Beiträge) 17:30, 15. Dez. 2009 (CET))

data-Journal

data=journal ist anscheinend in manchen Fällen sogar schneller als die anderen Journaling-Modi: [2] (nicht signierter Beitrag von 85.212.162.72 (Diskussion | Beiträge) 12:20, 9. Okt. 2005 (CEST))

schneller/langsamer als ReiserFS

Ich habe persönlich festgestellt, dass ext3 schnneller arbeitet als reiserFS. Deswegen verstehe ich diesen Punkt nicht: "Weiterhin ist ext3 langsamer als andere moderne Journaling-Dateisysteme wie zum Beispiel XFS oder ReiserFS." Deswegen würde ich eine Löschung dieser Stelle vorschlagen, ohne das es jemand wieder rückgängig macht. (nicht signierter Beitrag von 84.188.103.57 (Diskussion | Beiträge) 22:04, 30. Nov. 2006 (CET))

kleines Beispiel (nicht signierter Beitrag von 84.188.103.57 (Diskussion | Beiträge) 22:19, 30. Nov. 2006 (CET))

Nur weil es 2006 bei einem einzelnen Anwender schneller als Reiser war, sollte das nicht einfach geloescht werden. Vermutlich geht's bei "ReiserFS" ist schneller vor allem um die Performance mit user_xattrs oder kleinen Files. Und einfach aus dem Einzeltest von Reiser auf die Performanceunterschiede zu XFS zu schliessen ist eigentlich nicht moeglich. (nicht signierter Beitrag von 93.104.9.82 (Diskussion) 01:27, 6. Jun. 2011 (CEST))

Performance von data=journal

an verschiedenen Stellen heisst es, dass tatsaechlich data=journal der schnellste Modus ist, ohne dass bisher eine plausible Erklaerung dafuer existieren wuerde. Man sollte das evtl. einfuegen, da es fuer Anwender relevant ist, sowohl weil's schneller ist, als auch weil es relevant ist, dass das FS nicht gemaess der Erwartungen arbeitet... (nicht signierter Beitrag von 93.104.9.82 (Diskussion) 01:27, 6. Jun. 2011 (CEST))

Dann nenn bitte mal eine der "verschiedenen Stellen". Man müsste wissen, was und wie dort gebenchmarkt wurde, um das kommentieren zu können. --Echoray

H-Baum

In der Übersichtstabelle ist ein Verweis auf H-Bäume zur Verzeichnisstruktur. Der Link verweist auf die bereits mehrfach gelöschte Seite "H-Baum_(ext3)", als Löschungsgrund ist "Inhalt unsinnig" angegeben. Vielleicht sollten ext3-spezifische Details dazu im ext3-Artikel selbst anstatt in einem eigenen Artikel untergebracht werden. Nach einigen Kommentaren ist das bei ext3 ein HTree (engl., != H-Baum), was in der Implementation ein veränderter B-Baum ist. Die englische Seite hat an dieser Stelle übrigens einen Weblink zu http://ext2.sourceforge.net/2005-ols/paper-html/node3.html

--Luziferius (Diskussion) 18:32, 2. Mär. 2013 (CET)

Wiederherstellung gelöschter Daten

Im Abschnitt Kritik steht geschrieben, dass das Wiederherstellen gelöschter Daten schwierig sei, da die Block-Pointer der Inodes mit Nullen überschrieben werden. Ist dem so? Gibt es dazu eine Quelle?

Ich frage, da ich erst heute jede Menge gelöschte Dateien von einer Parition wiederhergestellt habe. Auf http://extundelete.sourceforge.net/ wird beschreiben, dass hierzu Informationen aus dem Journal genutzt werden. Dies widerspricht in meinen Augen der Aussage, dass diese Informationen beim Löschen genullt werden. --84.118.243.166 09:58, 18. Mär. 2016 (CET)