Shio schrieb:
Ich hab gar nichts getestet, hatte nur die 2GBps beim Kopieren gesehen und mir gedacht, dat läuft schon
Wie schnell es kopiert wird kann täuschen, da ja noch der Schreibcache involviert ist: Wenn es lt. Fortschrittsanzeige fertig ist, ist nur alles im Cache, der aber noch nicht vollständig geschrieben wurde.
Um beim kopieren die effektive Geschwindigkeit zu ermitteln, mache ich das so:
Code:
sync;time cp -avn Quellverzeichnis/* Zielverzeichnis/;time sync
Das erste sync erzwingt das schreiben den Schreibcachs, dann wird gemessen wie lange das kopieren dauert und anschließend das leeren des Schreibchachs: Die effektive Geschwindigkeit ist die kopierte Datenmenge durch die Summe beider Zeitmessungen.
Wie man das unter Windows macht, weiß ich nicht.
Shio schrieb:
Hatte die Tage aber nochmal geschaut und im Crystaldisk Benchmark sieht die Partition auf jeden Fall um einiges langsamer aus.
Auf Benches würde ich mich nicht verlassen. - Dazu hatte ich gerade was geschrieben:
Caramon2 schrieb:
sikarr schrieb:
Falls das der Stick ist
https://ssd-tester.de/sandisk_extreme_go_128gb.html
Steht er doch gar nicht so schlecht da wie du sagst, nicht das ein defekt vorliegt?
Benches sagen dabei überhaupt nichts aus: Ich hatte den Stick übergangsweise für einige Wochen als Systemlaufwerk für LinuxMint genutzt, inkl. Aktualisierungen usw.
Mich interessieren keine theoretischen Werte, sondern das was ich effektiv davon habe.
Ich würde einfach zwei gleiche große Partitionen auf den selben Datenträger erstellen, die eine mit ntfs-16k, die andere mit btrfs, auf beiden die selben Spiele installieren, vergleichen ob es spürbare, vielleicht sogar gravierende Unterschiede gibt (Ladezeiten und wenn im Spiel was nachgeladen werden muss) und dann entscheiden.
- ntfs wird unter Windows auf jeden Fall schneller sein und weniger das System belasten, wird bei Linux dank ntfs3 aber auch sehr schnell und ressourcenfreundlich sein, lässt sich allerdings immer noch nur unter Windows prüfen und reparieren (so viel zu "Microsoft loves Linux")
- btrfs ist unter Windows langsamer, hat aber mehr Möglichkeiten (subvols, zstd-Kompression, usw.) die angeblich auch WinBtrfs unterstützt (habe ich nicht getestet, da für Videoschnitt irrelevant).
Ich würde WinBtrfs aber schon wegen Microsoft nicht trauen, da sich bei Windows immer wieder gravierendes ändert, wodurch WinBtrfs vielleicht nach einen Windows-Update Probleme bekommt und im schlimmsten Fall die ganze Btrfs-Pattition schreddert: Sowas schafft Windows ja auch gut alleine und eine hobbymäßig erstellte, nicht offiziell unterstützte Dateisystemunterstützung verbessert das sicherlich nicht.
Gerade dass Windows
nicht auf meine Linux-Dateisysteme zugreifen kann, sehe ich als großes Sicherheitsplus, da es sich so nur selbst zerschießen kann.
…
Ich habe es gerade mit diesen Testdaten (Musik, Bilder, Videos) aus der RAM-Disk heraus auf zwei frisch formatierten 10G Partitionen ausprobiert:
Code:
1629 Elemente (1568 Dateien, 61 Ordner)
5,6 GiB (6.010.112.077 Bytes)
Zuerst setze ich die CPU auf Idle-Takt (
s. hier), damit Unterschiede bei der Systemlast deutlicher werden und dazwischen habe ich 5 Minuten gewartet, damit die SSD (eine 500 GB MX500: nicht das Systemlaufwerk, also keine anderen Zugriffe) den SLC-Cache schreiben kann:
Code:
$ gov s
powersave
4000000
$ sync;time cp -a /tmp/ramdisk/* /run/media/user/ntfs-Test/;time sync
real0m13,333s
user0m0,062s
sys0m13,089s
real0m6,404s
user0m0,000s
sys0m0,007s
$ sync;time cp -a /tmp/ramdisk/* /run/media/user/btrfs-Test/;time sync
real0m15,201s
user0m0,063s
sys0m14,965s
real0m10,036s
user0m0,000s
sys0m0,035s
"real" ist die tatsächlich benötigte Zeit, "user" und "sys" die CPU-Last der entsprechenden Benutzerebene.
Trotz identischer Partitionsgröße und Daten (und bei ntfs-16k größeren "Verschnitts"), ist bei btrfs weniger frei:
Code:
$ df -h /dev/sdb*
Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
/dev/sdb3 10G 5,7G 4,4G 57% /run/media/user/ntfs-Test
/dev/sdb4 10G 5,7G 4,2G 58% /run/media/user/btrfs-Test
btrfs nutzt zwar 16k Inodes, aber 4k Cluster und ich habe es mit
-m single formatiert, damit die Meta- und Systemdaten nicht doppelt abgelegt werden:
Code:
Block group profiles:
Data: single 8.00MiB
Metadata: single 8.00MiB
System: single 4.00MiB
