staging.inyokaproject.org

Hallo,

Revision zurück gesetzt und Nutzer per PN angeschrieben.

Ein Win-Dateisystem als "ideale Lösung" unter einen Nicht-Win OS zu propagieren ist schon seltsam ☺

Gruß, noisefloor

Liebe Hüter der Wiki Seite "Dateisysteme"

wie richtig in euren Thread festgestellt ist im Netz kein von anderer Stelle veröffentlichten Benchmark für Dateisysteme bei Dateien der Grösse 500 MB bis 4 GB (fallen an bei Audiobearbeitung, Videoschnitt) zu finden, der auch FAT32 enthält. Deshalb habe ich die Seite Dateisysteme diesbezüglich ergänzt. Zu Geschwindigkeiten oder Eignungen für besondere Anwendungen steht dort leider bisher gar nichts. Eine Ergänzung dahingehend wäre sinnvoll.

Nachdem ich dieselben Dateien (>1000 MB) sowohl in Windows als auch in Linux auf einem Dual Boot System mit mehreren Daten-Platten gleichen Typs hantiert habe, fiel mir ein signifikanter Geschwindigkeitsunterschied beim Kopieren bei unterschiedlichen Dateisystemen ext4, NTFS, FAT32 auf.

Ursache des Geschwindigkeitsunterschieds ist die auch bei einer einzigen Datei durch Linux erzeugte Fragmentierung über die gesamte Platte bei NTFS und ext4. Wenn ihr das nachvollziehen wollt: Leere Partition anlegen, 3 grosse Dateien mit je 1 GB in Linux kopieren und dann die belegten Bereiche auswerten, sie sind verteilt über 80% der Plattenoberfläche bei nur 2% Füllgrad (fast leere Platte). Bei NTFS kann man dies dann auch in Windows eindrucksvoll sehen und defragmentieren, dann wird das durch die Linux-Fragmentierung ausgebremste NTFS in Windows wieder schnell.

Eure Argumente bezüglich Zugriffsschutz, Journaling, Datensicherheit etc, sind alle richtig, kosten aber auch Geschwindigkeit. Ein Dateisystem, bei dem Linux grosse Dateien nicht fragmentiert und wenig Overhead mitschleppt, ist da für Audio-/Video-Schnittdateien viel schneller. Welches der anderen Dateisysteme leistet dies und ist für Dual Boot geeignet? Ich bin für gute Vorschläge offen, wenn diese durch Messungen gestützt sind.

Grüße guki49

P.S.: Die Obergrenze von 4 GB pro Datei wird erst am Ende unangenehm, wenn die mehreren kleineren Einzelteile alle zusammengesetzt werden. Aber für den grossen Output bei diesem letzten Schritt gibt es ext4 Platten (und meist bleibt man unter Spielfilmlänge)

P.S.2: Zu den Vergleichen: Die Geschwindigkeit ist immer auch stark von der Dateigrösse und Anzahl abhängig. FAT32 und NTFS sind bei grossen Dateien unter Windows ähnlich schnell, weil Windows grosse Dateien möglichst nicht fragmentiert. NTFS und ext4 sind unter Linux ähnlich "schnell" oder langsam, weil Linux in beiden Dateisystemen grosse Dateien fragmentiert und über die ganze Oberfläche verteilt. Aber: NTFS unter Windows ist signifikant schneller als unter Linux bei grossen Dateien. FAT32 unter Linux erscheint mir geringfügig schneller als NTFS unter Windows.

Lieber guki49

Die Einwände gegen Deinen Abschnitt sind mehr grundlegender Art, wobei es um zwei Argumente geht:

1) Ein Problemkreis ist, dass "Privatmessungen" (von Dir, aber natürlich übrigens ebenso von mir!) in einem Wiki etwas komisch aussehen. Geschwindigkeiten können von sehr sehr vielen Faktoren abhängen, das geht von hardwarespezifischen Eigenheiten des Testsystems bis zur Art der Dateien. Nicht einmal Fachzeitschriften sind sich bei Performance-Tests immer einig. Ich sehe es eigentlich nicht so ganz, dass wir anfangen, private Messungen dieser Art ins Wiki aufzunehmen. Das ist anders, wenn externe Quellen Messungen veröffentlicht haben - ist aber gerade bei der von Dir getesteten bzw. angesprochenen Konstellation nicht der Fall, wie Du korrekt selber schreibst.

2) Davon unabhängig ist FAT32 sehr stark veraltet. Du räumst die Nachteile dieses Dateisystems ja selber ein. Ich finde, dann müsste ein Geschwindigkeitsvorteil allgemein anerkannt sein (siehe aber eben dazu Punkt 1), dass das noch ein Argument für FAT32 sein könnte. Fragliche Datensicherheit ist zudem in meiner Haltung nicht recht mit Geschwindigkeit aufzuwiegen.

Ich behaupte jetzt mal, dass, wer viel mit grossen Mulimedia-Dateien arbeiten will, besser in gute Hardware investiert, statt FAT32 zu benutzen.

Lg X.

Hallo,

wie richtig in euren Thread festgestellt ist im Netz kein von anderer Stelle veröffentlichten Benchmark für Dateisysteme bei Dateien der Grösse 500 MB bis 4 GB (fallen an bei Audiobearbeitung, Videoschnitt) zu finden, der auch FAT32 enthält. Deshalb habe ich die Seite Dateisysteme diesbezüglich ergänzt. Zu Geschwindigkeiten oder Eignungen für besondere Anwendungen steht dort leider bisher gar nichts. Eine Ergänzung dahingehend wäre sinnvoll.

Das Wiki ist keine Ablagestelle für private Benchmarkmessungen - dafür gibt es Blogs, Webseiten etc.

Weiterhin ist der Artikel als Übersicht über die verschiedenen Dateisysteme unter Linux gedacht. Spezialfälle wie der von dir eingefügte sollten da nicht wirklich aufgeführt werden.

Gruß, noisefloor

Hallo und gute Nacht miteinander,

der Thread lässt mich leider nicht schlafen. Auf der Suche nach einer Erklärung, wie sich die langen Dateinamen unter Linux verhalten, bin ich hergekommen und bei 2009 (~s. 12) eingestiegen. Ist also mein 1. Beitrag hier. Juten Tach ooch! Lustige Unterhaltung mit gegenseitiger Achtung, was in Foren ja nicht immer üblich ist.

Zu einigen Sachen muss ich aber meinen Senf dazugeben!

Erstens

Interessant finde ich die Mühe, die Ihr Euch teilweise macht, wenn es um die Frage geht, dass es nun 255 Zeichen sind, wo man ein Zeichen aus diesem oder jenen Grund abziehen muss. Meistens ist es eine Zählweise. Ganz im Widerspruch dazu stehen scheinbar die Implementationsfehler der Programmierer/ Programme, die scheinbar vorwiegend in Redmond gepflegt werden. Besonders eindrucksvoll finde ich das Beispiel, wo am Ende des Limits auf der Konsole noch einmal eine letztlich nutzlose Datei mit weiteren 80 Zeichen erstellt werden kann. (Siehe auch: Zehntens B)

Dieses Beispiel zeigt, dass das Thema insgesamt von einer vollkommen anderen Seite angegangen werden muss. Die Thematik, die ich für M$ Produkte aufgezeigt habe, gilt in kleinerem Maße sicherlich auch für Linux. Die Grenzen bis 4096 Zeichen sind einfach mal flexibler.

Zweitens

Der Hinweis von guki49 mit dem Fat32 finde ich in der Grundidee nicht einmal so abwegig. Für die tägliche Praxis, mit höheren Anforderungen, ist das natürlich nix. Aber der Verwaltungsoverhead fällt weg. Fat32 findet auch auf SD-Karten Verwendung. Zum Rendern von Filmen sicherlich auch nicht das beste Medium. 😀 Für Spezialanwednungen kann aber so ein Dateisystem auch seine Berechtigung haben. Sicherheit, Redundanz und so ein Firlefanz fällt natürlich weg. Aber wer mal eine DVD nachbearbeiten will, kann mit dem Limit der 2 GB / 4 GB/Datei sicherlich auskommen.

Ich habe schon beim Lesen diese Variante eher als Swap-Laufwerk verstanden. Auschecken, bearbeiten ... wieder einchecken. Insofern kann ich der Rundumkritik an dem Vorschlag nicht zustimmen.

ABER: Die Performancevorteile sind natürlich weder belegt noch nachvollziehbar. Konfiguration und verwendete Programme sind nicht angegeben. M$ Defrag als Referenz, zur Belegung der Festplatte anzugeben, war allerdings mein Lacher des Tages!

Und auch hier muss ich Wasser in den Wein kippen: Die Kritik daran, dass Einzelmessungen nichts wert wären, kann nicht Bestand haben, weil ein beobachteter Effekt fängt nun einmal mit einer einzelnen, unstimmigen Beobachtung an. Wenn man erst warten würde, bis größere Zeitungsverlage oder Hersteller sich dazu aufraffen diesen Effekt nachzuvollziehen, dauert es i.d.R. laaaange. Und die ausschlaggebende Dokumentation, als Referenz, dazu abzuwarten ebenso. Irgendjemand muss ja den Anfang machen. Zumal dort auch Interessen verfolgt werden. Wieso sollte sich M$ hinstellen und für eine nicht massentaugliche Randanwendung ein altes Dateisystem propagieren? Wenn man das in Waschmaschinen und Rasenmäher einbauen könnte... ja, dann sicherlich! Ein vollkommen unerschlossener Markt!

Die Bedingungen, unter denen der Test gemacht wurde, MÜSSEN besser (möglichst vollständig) dokumentiert sein. Sonst nützt die Geschichte nicht einmal zum Rendern von Filmen < 4GB. Ob die Mühe sich lohnt, dafür eine Partition abzustellen und die ggf. sogar noch an den Anfang der Platte "zu schieben", mag die Frage noch einmal in ein anderes Licht rücken.

Drittens

Der Hersteller 'Tor am See' lieferte seine externen Festplatten (damals) 320 GB mit Fat32 aus.

Viertens

FatXX lässt sich dazu benutzen Dateien (mittels doppeltem Kopieren) von ALLEN anhängenden Rechten UND auch versteckten Daten (Streams / Mac: Forks) zu befreien. Kostet Zeit, funktioniert aber (auch für User ohne weitere Kenntnisse) sicher.

Fünftens

Jetzt geht es langsam ins Eingemachte.... Wieder zurück zum eigentlichen Thema: Das Dateisystem, seine Zählweisen und Grenzen Ich verweise auf einen Beitrag innerhalb dieses Threads, der darauf hinwies, dass "der Normaluser" die Beschränkungen des Dateisystems kaum erreichen wird. Eine ähnlich lustige These las ich kürzlich in einem Beitrag einer Computerzeitung, wo der Redakteur die These vertrat, dass 255 Zeichen wohl nie ein User ausnutzen wird. ... Hust! Ich erinnere die Senioren unter uns, wer damals schon einmal probiert hatte, die Disketten von Netzwerkkarten auf Festplatte zu bannen.

Da war SCHNELL Schluss mit Lustig:

1

Laufwerksbuchstabe:\Hersteller\Typ der Karte\Name der Karte\OS\Treibernummer PLUS die netten, lustigen Unterverzeichnisse, die auf der Diskette ihr Heim gefunden haben.

Das Verpacken in ZIP war zwar umzusetzen, aber weil auch das Auspacken wieder mit Risiken behaftet war und möglichst in die Root (einer Diskette) erfolgen sollte. Und der unbedarfte Empfänger, der von diesem Problem keine Ahnung hatte, dem das auch noch zu vermitteln... Der User hätte den Hinweis die ZIP-Datei unbedingt möglichst in einen Pfad mit kurzem Namen zu kopieren, ebenfalls bekommen müssen. – Schon 1990 keine echte Lösung und schon damals 'ein' Problem.

Sechtens

Leider bleibt Eure Diskussion zu dem Thema ein bisschen eindimensional. Ihr bleibt bei der Behandlung des Themas beim alleinstehenden Computer OHNE Netzwerkanbindung! Das ist aber schon seit einiger Zeit kein #Neuland mehr und sollte in der Betrachtung deswegen nicht untergehen!

Das Beispiel der Disketten mit Netzwerkkartentreibern zeigt, dass ganze Pakete mit Dateisammlungen (dazu gehören bei M$/IE auch die Funktionen: a) "Diese Seite als HTML mit Dateien speichern" UND b) das Lesezeichen (als einzelne Datei im Unterverzeichnis des Benutzers abgespeichert, PLUS den tollen Namen, den sich der Marketingexperte der interessanten Webseite ausgedacht hat, in der möglichst alle Schlagwörter der Webseite einmal vorkommen sollen. Die Speicherung erfolgt SELBSTVERSTÄNDLICH OHNE Prüfung (des OS und des Browsers) mit der vollen Länge des Dateinamens. Bei "HTML-Seite mit Dateien" kommt das Verzeichnis mit der Endung "Dateien von Tolle Seite" auch noch dazu.

Das Speichern funktioniert noch, aber spätestens das Umkopieren von Benutzerprofilen führt zu Ärger.

Siebtens A

Der Knaller beginnt allerdings erst jetzt! Der User / der Angestellte, der an seiner Workstation arbeitet, bekommt einen Netzwerkpfad "//servername/freigabename" schon mal direkt als Laufwerksbuchstaben gekürzt angeboten. Bei diesem Verschnitt brauchen wir uns nicht mehr über die Zählweise +/-1 Zeichen unterhalten. Auch dass unterschiedliche Programme die Grenze von 255-1 unterschiedlich zuverlässig berechnen, fällt dabei unter den Tisch.

In solchen Situationen MUSS mit einem wesentlich größeren Verschnitt gerechnet werden, der entsprechend kommuniziert werden muss.

Siebtens B

Hat der User / Mitarbeiter auf seinem lokalen Rechner also eine Datei gespeichert, kommt sie ins lokale Netz. (siehe 7a)

Der Admin hat aber an seinem Server ebenfalls mit dem Beschränkungen der 225 Zeichen zu rechnen. Mir ist nicht bekannt, dass M$-Server OSse eine andere Zählweise hätten, als die Workstations.

Hat der Admin also selber auch noch eine Struktur, muss man den Zeichenverbrauch dort auch noch einbeziehen! Mit:

1

"M:\data\Projektname für den Admin\Freigabename\Kundenname\Jahrgang\toller projektname\weitere Verzeichnisse\Toller Dateiname PLUS Extension"

... kommt da schnell an seine Grenzen.

Siebtens C

Das Problem wird ebenfalls vergrößert, wenn ein ursprünglich kurzer Verzeichnisname in der MITTE gegen einen "schöneren Namen" umgeändert wird. (Stichwort: "Sprechender Bezeichner" oder "Kopie von ... (ggf. plus Datum)") Die Datei, die gerade noch ins Schema passte, wächst nach hinten raus. Besonders lustig wird das, wenn der Projektleiter die tiefen Strukturen selber nicht mehr überblickt und am Anfang des Pfades rumschraubt und aufhübscht.

Siebtens D

Weiter verschärft wird das Problem mit den Dateinamen am Server, wenn die Daten (am Server) auf eine andere (größere) Platte umziehen müssen. D Da kommen die Dateinamen, die für den User im Netzwerk mit der "gekürzten Freigabe" gerade noch ins Limit passen, am Server in die Enge. Am Server lassen sich die Dateien nämlich auch nicht direkt ändern. Nur über Tricks oder vom Arbeitsplatz des Users bzw. über die gleiche Freigabe. Aber der Admin arbeitet doch wohl selten über die Freigaben, wenn er die Projekte selber kaum kennt.

Diese Aufgabe stelle sich bitte jeder Admin in einer größeren Firma mit mehr als 20 kreativen Mitarbeitern vor, wenn der Admin den Leuten hinterher rennen muss, damit die ihre Dateinamen kurz halten oder gar nachträglich umbenennen. ("WIESO? ... Bei mir klappt das doch!")

Siebtens E .. eigentlich Achtens

An der Stelle seinen noch die Backupprogramme erwähnt. Sie müssen ebenfalls mit den Dateinamen zurechtkommen. Ich möchte KEINE Wetten abschließen, ob da wirklich alles wieder hergestellt werden kann, was (zu) lange Dateinamen hat. Eventuell gibt es da noch andere Techniken mit langen Namen umzugehen....

Spätestens, wenn aber der User eine tief verschachtelte Struktur hat, die erfolgreich gesichert wurde und dann selber (nicht an der gleichen Stelle, sondern an einem anderen Ort wieder hergestellt wird) wieder in einer eigenen tiefen Struktur landet, addieren sich die jeweiligen Pfadlängen.

Neuntens

Unter M$ gibt es ein Commander Clon, der Dateien MIT langen Dateinamen kopiert und den User vor die Auswahl stellt, die Datei zu kopieren, abzubrechen oder die Datei umzubenennen. Der Hinweis, dass andere Programme das dann eventuell nicht lesen können, ist leider wenig vertrauenserweckend.

Zehntens A

Die letzten Punkte zeigen, dass die Datei und Pfadlänge beim Marktführer nicht absolut ist, SONDERN, dass sie nur auf dem lokalen Rechner gültig ist. Sobald Netzwerkfreigaben ins Spiel kommen, werden die Karten neu gezählt und die Längen können sich unerwartet verändern.

In einem zu langen Pfad am Server kann ich also auch zugreifen, wenn ich eine weitere Freigabe in einem tief gelegenen Verzeichnis anlege und die Daten von dort auslese / manipuliere. Aber auch das kann nur ein Notbehelf sein. Eine Dauerlösung, von der aus weiter die Strukturen verfeinert werden, darf das wohl nicht sein.

Zehntens B

Manuelle Hilfe beim eingetretenen Gau kann es auch sein, die Verzeichnisnamen am Anfang/Mitte ein wenig einzukürzen und damit am Ende des Pfades wieder Luft zu bekommen. Pfade zu Datenbanken / sich gegenseitig referenzierenden / abhängigen Dateien o.ä. dürfen natürlich nicht betroffen sein, weil diese nachträglich ebenfalls geändert werden müssen. Oder es muss nach der Änderung der Ursprung wieder hergestellt werden.

Schluss

Gilt "natürlich" und "alles" "nur" für das Produkt aus "Roter Mond". 😉 Beim Pinguin dürfte es bei einer "offiziellen" Obergrenze von 4096 ein bisschen mehr Luft geben.

Die Diskussion aber auf lokale Workstations mit Linux und OHNE Datenaustausch zu anderen Rechnern (zzgl. externe Festplatten / Netzwerk) zu beschränken dürfte zu kurz gedacht sein. Spätestens wenn die Daten Linux verlassen und auf einem Rechner mit dem OS des Platzhirschen betreten, kommen diese Probleme wieder auf einen zu. 4096 Zeichen großzügig auszureizen und dann noch mit Anderen Spielen zu wollen wird zum K.O.

Dieser Ausflug sollte zeigen, dass die Diskussion mit "255-1 plus Rundungsfehler" zu klein dimensioniert ist. Es müsste eine Berechnung aus drei Teilen bestehen: a) Länge von Laufwerksbuchstabe bzw. Freigabename b) Länge des Pfades c) Länge des Dateinamens zzgl. Extension d) Plus alle: "/ \ . und Leerzeichen"

Doch noch Elftens

Der Mac hat dann noch mal andere Spielregeln. Wie gut die heute mit Linux zusammenspielen, kann ich nicht sagen (HFS ⇒ HFS+ ⇒ APFS ⇒ ... erlaubte Zeichen im Dateisystem [* / \ ? " etc.])

BTW: Was sagt eigentlich "die Cloud" zu Dateinamen und Pfadlängen? Und die jeweiligen Übertragungsprogramme?

Das dreckige Dutzend

Wesentlich schneller würden Rechner übrigens, wenn sie nicht für jeden Furz ständig übergroße Objekte durch den Speicher jagen müssten (objektorientierte Sprachen), in denen sich vom kopierten Buchstaben B noch sämtliche anderen Inkarnationen seiner selbst, mitsamt all seiner Formatierungsvarianten und Schattenseiten befinden, obwohl man doch nur ein B benötigt. Kopiert wird erst mal ALLES. Was davon benutzt wird, "wählt" der User erst beim Einfügen. (Und es soll größere Objekte, als das B geben!) Maschinensprache würde auch noch mal einen kleinen Schub bringen!

Noch ein abschließender Witz zum Thema: Unsinnig viele Daten durch die Welt schicken

(M)ein Prüfer bei der IHK wollte doch ernsthaft eine komplette Datenbank (1 GB) im Repository einer Versionsverwaltung speichern. Auf meine verblüffte Frage: "Wieso?", kam er mit: "Es geht doch! Dann hat jeder die gleiche Datenbank." – Wie schnell so eine Datenbankdatei veraltet... und das Repository aufgefrischt werden müsste. 😀 Nun ja. Da ist der Bock wohl zum Gärtner geworden. Sicherlich alles nur Provokation zur Prüfung!

Mit einem bereits morgentlichen Gruß

Wolfgang

Ich habe den Artikel leider kaputtgemacht, ich bekomme immer Bad Gateway.

Hallo,

der Artikel ist korrigiert - du hattest die schließenden || vergessen.

Tipp: mit https://wiki.ubuntuusers.de/Dateisystem/a/edit kann man den Artikel (immer?) öffnen.

Mein Edit ist auch übernommen (siehe https://wiki.ubuntuusers.de/Dateisystem/a/log/) - aber der Bad Gateway bleibt. Keine Ahnung, woran das liegt (Caching?) → IMHO ein Fall für das Webteam.

Gruß, noisefloor