staging.inyokaproject.org

Also lassen wir den Hinweis vorerst mal drin?

Gruß - Max-Ulrich

Hallo,

also habe gerade mal nach "reiserfs ppc" bei Google gesucht. Das war wohl mal so, ist aber scheinbar abgestellt. Jedenfalls sind die gefunden Webseiten / Infos alle min 4 Jahre alt...

IMHO kann's raus.

Gruß, noisefloor

IMHO kann's raus.

Done.

Gruß - Max-Ulrich

Der Link in der Kopfzeile der Tabelle ganz rechts "Journaling" ist tod. ☺

http://wiki.ubuntuusers.de/Dateisystem?redirect=no#Grundlegende-Merkmale

Danke, mit Wikipedia-Link gefixt.

Das nächste mal kannst Du das selber machen. Siehe Unterschiede ☺

Selflinux.org ist nicht mehr unter der www-Adresse zu erreichen.

kaputtnik schrieb:

Danke, mit Wikipedia-Link gefixt.

Das nächste mal kannst Du das selber machen. Siehe Unterschiede ☺

---

Selflinux.org ist nicht mehr unter der www-Adresse zu erreichen.

Alles klar. ☺ Ich bin nur noch relativ neu hier (=

Im Artikel wird fälschlicherweise behauptet, Pfadnamen in Linux dürften maximal 4096 Byte lang sein. Ähnliches wird auch unter http://en.wikipedia.org/wiki/Comparison_of_file_systems#cite_note-note-12-14 behauptet. Ich habe mir ein kleines Skript geschrieben, um das zu testen:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

#!/bin/bash

NAME=ABCDEFGHIJKLMNOPQRSTUVWXYabcdefghijklmnopqrstuvwxy
i=0
while ((++i))
do
	mkdir $NAME
	cd ./$NAME
	echo $i
	sleep 0.01
done

Auf einem USB-Stick unter /run/media/USERNAME/STICKNAME/ habe ich dieses Skript laufen lassen. Bis zur Ausgabe von 2570 ist das auch erfolgreich, dann gibt es Fehlermeldungen:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

2568
2569
2570
/home/christian/scripts/test-max-dir-depth.sh: Zeile 10: /usr/bin/sleep: Die Argumentliste ist zu lang
/home/christian/scripts/test-max-dir-depth.sh: Zeile 7: /usr/bin/mkdir: Die Argumentliste ist zu lang
/home/christian/scripts/test-max-dir-depth.sh: Zeile 8: cd: ./ABCDEFGHIJKLMNOPQRSTUVWXYabcdefghijklmnopqrstuvwxy: Der Dateiname ist zu lang
2571
/home/christian/scripts/test-max-dir-depth.sh: Zeile 10: /usr/bin/sleep: Die Argumentliste ist zu lang
/home/christian/scripts/test-max-dir-depth.sh: Zeile 7: /usr/bin/mkdir: Die Argumentliste ist zu lang
/home/christian/scripts/test-max-dir-depth.sh: Zeile 8: cd: ./ABCDEFGHIJKLMNOPQRSTUVWXYabcdefghijklmnopqrstuvwxy: Der Dateiname ist zu lang
2572
/home/christian/scripts/test-max-dir-depth.sh: Zeile 10: /usr/bin/sleep: Die Argumentliste ist zu lang
/home/christian/scripts/test-max-dir-depth.sh: Zeile 7: /usr/bin/mkdir: Die Argumentliste ist zu lang
/home/christian/scripts/test-max-dir-depth.sh: Zeile 8: cd: ./ABCDEFGHIJKLMNOPQRSTUVWXYabcdefghijklmnopqrstuvwxy: Der Dateiname ist zu lang
2573
[…]

Ich habe also einen Pfad mit 131100 Zeichen erstellt (128526 wenn man die / nicht mitzählt). Dieses Ergebnis ist exakt reproduzierbar auf allen getesteten Dateisystemen (fat16, fat32, xfs, btrfs, ext2, ext3, ext4), Ursache ist also wohl der Kernel. Auffällig war, dass die NTFS-Partition um mehrere Größenordnungen langsamer ist als die anderen Dateisysteme. Ein Verzeichniswechsel braucht dort nach einiger Zeit mehrere Sekunden (!) mit 100% CPU-Last auf einem Prozessorkern, das liegt wohl am FUSE-Treiber. Ich habe den Test daher abgebrochen.

Noch eine Notiz zum Testsystem: Ziel war ein USB-Stick, die Software lief unter Fedora 18 mit allen Updates.

Im Artikel wird fälschlicherweise behauptet, Pfadnamen in Linux dürften maximal 4096 Byte lang sein

Ich bezweifle, dass man da überhaupt allgemeine, d.h. vom jeweiligen Dateisystem unabhängige Aussagen machen kann. Ich frage mich aber, ob das wirklich so relevant ist. Ich habe nur ganz selten Probleme mit der Länge von Pfadnamen gehabt. Ich erinnere mich, dass es Programme gab (ich glaube, es handelte sich um einen Musik-Player, Audacious ??), die mit den neuerdings sehr langen Pfadnamen des GVFS in FUSE Probleme hatten, aber das lag sicher an den Anwendungsprogrammen und nicht am Dateisystem.

Mein Vorschlag: Hier einfach auf allgemein gültige Aussagen verzichten und statt dessen einen Hinweis einfügen, dass bei allen Dateisystemen die zulässigen Längen für Pfadnamen unterschiedlich begrenzt sind, die Grenzen aber in der Größenordnung von über 1000 Zeichen liegen.

Auffällig war, dass die NTFS-Partition um mehrere Größenordnungen langsamer ist als die anderen Dateisysteme.

Da wird es drauf ankommen, mit welchen Optionen die NTFS-Partition gemountet ist. Denn z.B. bei den Optionen permissions und acl gibt es u.U. eine ganz schöne Menge von Meta-Informationen. Mit NTFS-3G kann man zwar NTFS jetzt als vollwertiges Linux-Dateisystem verwenden, aber viele Operationen sind halt wegen der dafür nötigen Umwege deutlich langsamer. Das ist normal. NTFS wurde halt ursprünglich nicht für LINUX entwickelt 😕 .

Besonderheiten von NTFS-Treibern würde ich in diesem Artikel ganz außen vor lassen und nur auf die Artikel Windows-Partitionen einbinden und NTFS-3G verlinken.

Gruß - Max-Ulrich

EDIT:

Dass Du in allen Dateisystemen Pfadlängen von 131100 Zeichen erstellen konntest, bedeutet ja noch nicht, dass die Dateisysteme und die Dateisystem-Treiber dann auch mit diesen Pfadnamen fehlerfrei umgenen können. Ich wäre da vorsichtig.

Jo, es ging mir auch prinzipiell nur darum, zu zeigen, dass die Angabe im Artikel falsch ist.

Berechne doch mal die bytes des Strings, zB

$ echo /ABC | wc -c
5

Da ich nicht genau weiß, wie ihr das in der Wiki handhabt, wollte ich erstmal hier auf Unstimmigkeiten hinweisen. Es geht um den Abschnitt "Weitere Merkmale" Spalte "Nicht erlaubte Zeichen"

Neben / ist das Zeichen Null bzw. \0 auch nicht erlaubt (soweit ich weiß, bei alle Dateisysteme).

Desweiteren sind bei NTFS ebenfalls nur / und \0 nicht erlaubt, nur Windows verbietet die andere Zeichen. Daher finde ich, sollte in der Spalte nur / und \0 stehen und vielleicht ein Sternchen dahinter und unter der Tabelle auf die Einschränkung von Windows Explorer hinweisen.

Zumindest benachteiligt man NTFS so nicht 😉

Hallo,

habe das mit NFTS mal korrigiert - ok so?

Das mit \0 ist meine ich richtig, so wie du es sagst - bin aber nicht sicher... Hast du eine Quelle für deine Aussage?

Gruß, noisefloor

Klar ☺

http://de.wikipedia.org/wiki/NTFS

Allerdings gibt es dort keine Quellenangabe. Und bei MS ist das nicht aufgelistet
http://windows.microsoft.com/de-de/windows-vista/file-names-and-file-name-extensions-frequently-asked-questions
habe ich aber auch nicht erwartet 😉

im rechten Kasten unter "Maximalwerte"
Wenn ich mich nicht irre, gilt das für die andere Dateisysteme auch. Bin aber nicht sicher. Müsste aber, weil in C das ja als String-Ende genutzt wird. Ich meine das bei btrfs auf der Kernel Wiki auch gelesen zu haben...

Hier gibt es übrigens noch eine Diskussion dazu
http://forum.ubuntuusers.de/topic/dateinamen-mit-pipe-im-namen/#post-1381340
Und hier steht noch was bezüglich Zeichenketten http://de.wikipedia.org/wiki/Zeichenkette#Repr.C3.A4sentation_mit_Abschlusszeichen

Tja, wer hat Lust alle Dateisysteme zu testen? 😀

Hallo Ihr Lieben

Ich habe grösste Bedenken die neuste Ergänzung von guki49 im Artikel zu belassen. Der nahezu inaktive User (was den Inhalt an sich nicht bewertet, aber immerhin erwähnt sei) hat folgenden Absatz eingefügt:

Dateisysteme, Dateigröße, Fragmentierung und Geschwindigkeit

Unter Linux werden die Dateien möglichst günstig über den ganzen Plattenbereich mit freien Zwischenräumen verteilt, was für kleine und mittlere Dateigrößen sich änderner aktiver Daten günstig ist. Für sehr große Audio- und Video Dateien auf ext2/3/4 und NTFS wird allerdings durch das Zerstückeln die Geschwindigkeit stark beeinträchtigt, da viele Bewegungen des Schreib/Lesekopfs notwendig werden. Das Dateisystem FAT32 mit möglichst großen Zuordnungseinheiten (von 32 KB) liefert ein Mehrfaches an Geschwindigkeit gegenüber NTFS oder ext4. In Zahlen für das Schreiben derselben ca. 840 MB Datei auf derselben Platte mit unterschiedlichen Dateisystemen: Dateisystem Datei-Geschwindigkeit Platten-Leistung "roh" laut Laufwerksverwaltung NTFS 15,3 MB/s 155/120/65 MB/s (RAID 0) Datei von Linux fragmentiert geschrieben NTFS 14,0 MB/s 80/65/35 MB/s Datei von Linux fragmentiert geschrieben ext4 14,0 MB/s 80/65/35 MB/s Datei von Linux fragmentiert geschrieben FAT32 47,8 MB/s 80/65/35 MB/s Datei von Linux als Block fortlaufend geschrieben Geschwindigkeitssteigerung: FAT32 3,4 mal schneller als ext4. Fazit: Für das Bearbeiten großer Audio- und Video Dateien lohnt sich eine eigene Partition (1. Partition am Anfang = außen auf der Platte), die speziell mit FAT32 formatiert ist ("sudo mkdosfs /dev/sdxy -s 64 -F 32")

Mal abgesehen davon, dass der Abschnitt natürlich konform formatiert werden müsste und zahlreiche sprachliche Fehler und Unzulänglichkeiten enthält: Ich halte das ehrlich gesagt inhaltlich für Unsinn. Für eine behauptete derart massive Geschwindigkeitsvorteil von FAT32 müsste mindestens eine seriöse Quelle her. Selbst nur oberflächliche Recherchen geben nichts Derartiges her. FAT32 ist unter Windows ganz unbedeutend schneller als NTFS, für den Vergleich mit EXT4 habe ich auf die ganz Schnelle nichts Aussagekräftiges gefunden; EXT4 gilt aber eher als etwas schneller als NTFS.

Völlig daneben, geradezu drollig unbeholfen ist der Tipp, FAT32 könne man wegen dem angeblichen, von mir hiermit bezweifelten Geschwindigkeitsvorteil besonders gut für grosse Audio- und Videodateien benutzen. Nein, wirklich nicht! FAT32 kennt eine Begrenzung der Dateigrösse auf 4GB, was z. B. gerade bei grossen Audio- und Videodateien überschritten wird! Dann muss man die Dateien splitten, was ein elendes Gefummel ist; gegenüber diesem Aufwand ist der angebliche Geschwindigkeitsvorteil in jedem Fall ein Witz. 2016 ist die Verwendung von FAT32 in folgenden Fällen empfehlenswert: in keinen. Das Dateisystem hat zahlreiche weitere Nachteile, insbesondere ist es auch unsicherer bezüglich Datenverlust, so dass von seiner Verwendung in jedem Fall lebhaft abzuraten ist.

Ich plädiere für die ersatzlose Löschung dieser Ergänzung. Ich denke aber, dass eine Zweitmeinung hierzu angebracht ist.

Lg X.

Xeno schrieb:

Mal abgesehen davon, dass der Abschnitt natürlich konform formatiert werden müsste und zahlreiche sprachliche Fehler und Unzulänglichkeiten enthält: Ich halte das ehrlich gesagt inhaltlich für Unsinn.

Da bist du nicht der Einzige.

Für eine behauptete derart massive Geschwindigkeitsvorteil von FAT32 müsste mindestens eine seriöse Quelle her.

Zumal es vollkommen ungeeignet für den genannten Zweck ist, das dort in der Regel Dateien größer als 4GB anfallen werden.

EXT4 gilt aber eher als etwas schneller als NTFS.

NTFS wird unter Linux mittels FUSE eingebunden und ist schon alleine dadurch weitaus langsamer als Ext4 unter Linux. Also müsste man da eher NTFS unter Windows gegen Ext4 unter Linux vergleichen.

Ich plädiere für die ersatzlose Löschung dieser Ergänzung. Ich denke aber, dass eine Zweitmeinung hierzu angebracht ist.

Als Zweitmeinung eines Supports von "System einrichten und verwalten", schonmal: Full ACK.

2016 ist die Verwendung von FAT32 in folgenden Fällen empfehlenswert: in keinen.

Also mir würden da schon ein paar einfallen. Aber keine, die in den Artikel gehören würden. 😉

EDIT: Und schaue ich mir den einzigen Forenbeitrag an würde ich seine Platte nicht mal subjektiv als Kriterium für solche Messungen ansehen.