NTFS vs EXT4



  • Hallo,

    warum benutzt Windows nicht einfach ein EXT4 ähnliches Dateisystem wenn dieses doch viel besser ist. Als Nachteile von NTFS wird ja immer beschrieben dass es zur Defragmentierung neigt und sehr langsam beim Verschieben von Dateien ist. EXT4 hat diese Probleme nicht. Aber Microsoft hat ja seine Gründe das es NTFS verwendet.



  • LinuxBoy schrieb:

    warum benutzt Windows nicht einfach

    Kompatibilität.



  • Was soll "langsam beim Verschieben von Daten" bedeuten? Kann ich mir nix drunter vorstellen.

    Und was das Fragmentieren angeht: das liegt denke ich eher an der konkreten Umsetzung in Windows als daran wie die NTFS-Datenstrukturen aussehen. D.h.: MS könnte da nachbessern ohne die Kompatibilität zu beeinträchtigen.



  • Ich stelle jetzt einfach mal die Prämisse, dass ext4 "viel besser" ist, in Frage...



  • Das Thema Fragmentierung ist bei SSDs auch hinfällig.



  • Wenn du in Windows Dateien verschiebst dann rödelt Windows ganz schön. Um mein Android SDK von einem Ordner in den anderen zu verschieben , das hat fast 10 Minuten gedauert. In Linux wird das intern einfach umgehängt und in Null komma nix fertig.



  • Sicher dass es das gleiche volume war? So dumm wird windows ja nicht sein, zumal das dann auch nicht an ntfs liegt.



  • Ja es war das gleiche Volume. Von C:/ordner1/ordner2/ordner3/Android-SDK nach C:/



  • Linuxer schrieb:

    Ja es war das gleiche Volume. Von C:/ordner1/ordner2/ordner3/Android-SDK nach C:/

    War das in AppData? Könnte sein das er dann sämtliche Dateirechte geändert hat, weil es aus dem Userordner rausgezogen wurde.



  • Linuxer schrieb:

    Wenn du in Windows Dateien verschiebst dann rödelt Windows ganz schön. Um mein Android SDK von einem Ordner in den anderen zu verschieben , das hat fast 10 Minuten gedauert. In Linux wird das intern einfach umgehängt und in Null komma nix fertig.

    Boah, Sorry!
    Hab' wieder nicht ordentlich gelesen 🙄
    (Hab "Daten" gelesen dabei hast du "Dateien" geschrieben - was mit Verschieben von Dateien gemeint ist hätte ich natürlich verstanden. *facepalm*)

    Ich kann deine Beobachtung aber nicht nachvollziehen. Wenn ich Verzeichnisse auf dem selben NTFS Volume verschiebe dann geht das auch schnipp-schnipp.

    Aus wie vielen Files besteht das Android SDK ca. - nur damit ich ne Vorstellung bekomme?



  • Tobiking2 schrieb:

    Linuxer schrieb:

    Ja es war das gleiche Volume. Von C:/ordner1/ordner2/ordner3/Android-SDK nach C:/

    War das in AppData? Könnte sein das er dann sämtliche Dateirechte geändert hat, weil es aus dem Userordner rausgezogen wurde.

    Ne, beim Verschieben tut Windows die ACLs nicht anpassen. Nur beim Kopieren ändert sich da 'was.



  • ja es war glaub ich in AppData . DAS Android SDK ist ca 20 GB gross 🙂



  • 20 GB sagt jetzt genau nix über die Dateianzahl.



  • lol aber die Daten sind bestimmt wahnsinnig vertreut und sicherlich nicht in 1 Block.

    Die Anzahl der Dateien kann ich dir leider nicht sagen. Aber da sind auch viele Tools und so dabei



  • hustbaer schrieb:

    20 GB sagt jetzt genau nix über die Dateianzahl.

    Ist das nicht egal? Wenn die ACL nicht angefasst werden, muss ja nur das NTFS-Gegenstueck zum dirent des obersten Verzeichnis geaendert werden, oder?

    Der Thread ist in meinen Augen Getrolle, aber die daraus resultierende Diskussion finde ich nicht voellig uninteressant.



  • hustbaer: Moment, mir faellt gerade ein Grund ein, warum du die Dateianzahl vielleicht spannend finden koenntest. Windows hat ja diverse Locking-Mechanismen, dh. uU. muss gecheckt werden, ob es irgendwelche Locks auf eine der vielen Dateien im Ordner geben koennte, bevor ein rename durchgeht? Wolltest du auf sowas hinaus?

    stat ist unter Windows ja z.B. deutlich teurer als unter unixoiden Betriebssystemen, falls bei dem hypothetischen Lock-Check etwas aehnliches passiert wie bei einem stat, waere das halbwegs plausibel.

    Sorry wenn das alles Bloedsinn ist, ich habe von Windows keine Ahnung.



  • Die Dateianzahl deswegen, weil wenn überhaupt dann nur die einen Unterschied machen könnte. Und wenn ich die wüsste könnte ich es einfach mal ausprobieren. Die Grösse spielt dabei ja überhaupt keine Rolle.

    Ob es bei NTFS nen Unterschied macht weiss ich nicht, weil ich nicht weiss ob NTFS z.B. sowas wie einen Index über den vollständigen Pfad hat. Der müsste dann nämlich abgepasst werden. Und da macht es natürlich nen Unterschied ob man 2 oder 20.000 Einträge anpassen muss.

    Was Locking angeht: kann schon sein dass das da auch nen Unterschied macht, aber wenn das schlau implementiert ist skaliert das nicht mit der Anzahl der zu verschiebenden Files sondern mit der Anzahl an aktuell gehaltenen Locks. Quasi ein "foreach locked_file: check if full path begins with XYZ" und nicht ein "foreach file in files_to_move: check if locked".
    Und dieser Faktor müsste sich auch auf SSDs bemerkbar machen, und auf SSDs verschiebe ich öfter mal Verzeichnisse mit > 10 GB mit > 100K Files drinnen. Und das dauert so im Bereich ne Sekunde - auf jeden Fall GANZ weit weg von ner Minuten geschweige denn 10.


  • Mod

    hustbaer schrieb:

    wenn das schlau implementiert ist

    Ich habe eine Ahnung, was das Problem sein könnte 😃



  • nman schrieb:

    hustbaer schrieb:

    20 GB sagt jetzt genau nix über die Dateianzahl.

    Ist das nicht egal? Wenn die ACL nicht angefasst werden, muss ja nur das NTFS-Gegenstueck zum dirent des obersten Verzeichnis geaendert werden, oder?

    So eine Entsprechung ist naheliegend anzunehmen. Wenn ich nen kompletten Ordner verschiebe, ist es wurscht, wieviel drinsteckt, vorausgesetzt, es ist im gleichen Vol. Es rappelt kurz, fertig.

    Achso, falls von Interesse: NTFS stammt aus der Zeit des Kriegs von MS gegen IBM, WinDOS gegen OS/2. Die hatten gemeinsam HFS entwickelt und nach Beendigung der Zusammenarbeit hat MS ein paar Marginalien geändert und Journaling draufgesetzt, um zu OS/2 inkompatibel zu werden. IBM hat dann noch JFS nachgelegt, aber da war die Sache schon tot.



  • Wie gesagt, die File-Anzahl IM Ordner könnte dann interessant werden wenn es sowas wie einen "full path" Index gibt. (So ein Index wäre ja zum schnellen Aufmachen von Files die in einer tiefen Verzeichnishierarchie ganz unten stecken durchaus interessant.)

    Scheint es bei NTFS aber nicht zu geben. Zumindest hab' ich bei meiner kurzen Googelei zu dem Thema nichts gefunden wo so ein Index erwähnt würde.


Anmelden zum Antworten