Extrem große Cluster bei NTFS und exFAT

Caramon2 schrieb:
Dann wollte ich noch nachsehen, was es dort an versteckten Dateien gibt, aber "dir /a" machte irgendwelchen Mist und die Hilfe konnte ich auch nicht aufrufen:
Kein Wunder. Du hast ja auch die PowerShell aufgerufen. Dort ist dir nur ein Alias für Get-ChildItem. Du als Linuxer hättest auch ls statt dir nehmen können. Der Parameter den du suchst lautet -Force. Hilfe bekommst du mit Get-Help Get-ChildItem, oder für Tippfaule: man ls.
 
  • Gefällt mir
Reaktionen: Caramon2 und ufopizza
Ups, hatte das hier ganz vergessen… :)

Nach den ganzen Tests (s. u. - aus Mails an Bekannte), hatte ich erst mal genug davon und bin dann drüber weg gekommen.

Bzgl. der extremen Clustergrößen bin ich zum Schluss gekommen, dass die keine Vorteile bieten, sondern nur eingeführt wurden, um die Unzulänglichkeiten der Dateisysteme zu kaschieren:

FAT wurde ursprünglich für Disketten entwickelt und ist für heutige Datenmengen (und entsprechend viele Dateien) rel. ungeeignet und ntfs muss für sehr große Partitionen eben so große Cluster nutzen, da es ein (nicht mehr zeitgemäßer) 32bit-Oldtimer ist.

Ich muss ntfs/fat für DVB-Aufnahmen und -Bearbeitung nutzen (reines Stream-Copy, also nur große Datenmengen schaufeln), da weder meine Satreceiver noch Windows vernünftige Dateisysteme unterstützen, und dafür sind (egal ob Windows oder Linux) 64k Cluster am schnellsten:
  • mit kleineren Clustern wird es langsamer
  • mit 128k und 256k wird es nicht schneller
  • und mit noch größeren Clustern wird es wieder langsamer
(ex)FAT(16/32) formatiere ich generell mit 64k, da geringstmöglicher Verwaltungsaufwand und für sehr viele kleine Dateien sowieso das falsche Dateisystem.

ntfs formatiere ich je nach Einsatzzweck mit 4k oder 64k.

Wobei für ntfs 16k Cluster eine sinnvolle Alternative sein könnten: Das unterstützt zwar keine Datenträgerkomprimierung (nur bis 4k), aber da aktuelle SSDs lt. div. Quellen intern mit 16k Sektoren *) arbeiten, sind kleinere Cluster tendenziell kontraproduktiv.

*) Edit: mit Page-Größen (lt. Wikipedia):
Bis 2022 wurde die Page-Größe sukzessive auf bis zu 16 kB vergrößert.

Die Tests mit den Satreceivern:
Ich habe weiter bzgs. Satreceiver getestet:

Da damals am Xoro 8500 (2010 gekauft) eine HD mit ntfs während der Aufnahme durchgehend sehr starke Kopfbewegungen hatte (als würde eine PATA ohne NCQ defragmentiert), ließen sich Platten dort nur mit fat32-64k vernünftig betreiben. - Auch ntfs-64k brachte keine deutliche Linderung.

Da ich am neueren 8590 (2015) noch keine HDDs betrieben habe und das im Zuge meiner momentanen "Experimente" testen wollte, habe ich auch der alte 40 GB Samsung P80 PATA (also keinesfalls NCQ) drei keine Partitionen erstellt (damit alle im schnellen Bereich sind), mit ntfs-4k, ntfs-64k und fat32-64k formatiert und per USB-Adapter dort angeschlossen:

Bei keiner der Partitionen kam es zu starken Kopfbewegungen: Selbst mir zwei parallelen ÖR-HD-Aufnahmen, wovon ich eine um eine Minute zeitversetzt habe wiedergeben lassen, also das Maximum an provozierbaren Datenzugriffen, blieb die Platte noch rel. ruhig.

Bei ntfs-4k tat sich noch am "meisten", hörte sich aber noch vollkommen unkritisch an. Mit ntfs-64k blieb sie einen Hauch ruhiger und bei fat32-64k blieb sie nochmals etwas ruhiger (deutlicher als ntfs 4k->64k), also mit fat32-64k funktioniert" auch der 8590 am besten.



Aber auch SSDs haben am 8500 Probleme:

Als ich die 512 GB SSD (ntfs-4k) dort getestet habe, dauerte ein Aufnahmestart ca. 12 Sek., vom drücken der Taste, bis die Aufnahme tatsächlich startet. - Da es möglich ist, dass es auch zu dieser Verzögerung kommt, wenn für die laufende Aufnahme eine weitere 4 GB Datei angelegt werden muss (auch auf ntfs teilt der Satreceiver die Aufnahme alle 4 GB), könnte es dann zu den gleichen Problemen kommen, die ich damals auf langsamen Stick und fat32 mit zu kleinen Clustern hatte: Die Aufnahme ist beschädigt und die Wiedergabe bricht an der Stelle ab.

Auch bei der 120 GB SSD (ntfs-4k) dauerte das noch ca. 3 Sek. Also eine lineare Abhängigkeit von der Kapazität. Deshalb hatte ich die Partition auf 80 GB (=2 Sek. Verzögerung) reduziert.

Das habe ich heute Morgen getestet:

ntfs-4k: ca. 3 Sek. (nochmal getestet, da es frisch formatiert vielleicht Unterschiede gibt)
ntfs-64k: ca. 0,1 Sek.
fat32-64k: ca. 0,3 Sek.

Da ntfs aber bei beiden Satreceivern bei der laufenden Aufnahme schlechtere Datenträgerzugriffe hat *) und es unter Linux weder geprüft, noch getrimmt (ntfs3) werden kann, was beides mit (ex)FAT(16/32) inzwischen problemlos funktioniert, werde ich die 120 GB SSD (am 8500 = nur für Aufnahmen) doch mit fat32-64k formatieren, nachdem ich sie bisher ntfs-4k-formatiert hatte, da ich das als das bessere FS für SSDs angesehen hatte.

Was ich mit der 512 GB SSD (am 8590 = primär für Wiedergabe) mache, muss ich mir noch überlegen:

Bisher ist die mit ntfs-4k formatiert und schon weil sie ca. 150 GiB Daten enthält, möchte ich sie nicht neu formatieren, um das nicht erst wieder drauf kopieren zu müssen.

Aber selbst wenn: Wäre fat32-64k wirklich besser?

Kommt es zu Problemen (der 8590 hängt sich bei Aufnahmen mitunter auf), könnte das zu Datenverlusten führen, während ntfs nicht so fehleranfällig ist.

Außerdem muss ich dann bei geschnittenen längeren/HDTV Aufnahmen aufpassen, nicht über das 4 GiB Limit zu kommen (exFAT unterstützen beide Satreceiver nicht).

Aber auch die Formatierung auf ntfs-64k macht wenig Sinn:

Es ist zwar theoretisch schneller, aber praktisch kann man das selbst an den Kopfbewegungen bei der uralten HD kaum bemerken.

Höchstens wenn ich sie bei Bedarf am 8500 nutzen möchte, könnte das ein gravierender Vorteil sein. - Aber lohnt sich dafür der Aufwand?

Ich denke, ich werde ntfs-4k/-64k erst noch auf Sticks miteinander vergleichen: Falls sich dort gravierende Unterschiede zeigen, werde ich obiges ggfs. neu bewerten.



*) bei HD-Aufnahmen auf Sticks wird das deutlich:

Auf fat32-64k treten bei beiden Satreceivern nur sporadisch kurze Aussetzer und Haker auf, während ntfs dafür praktisch unbrauchbar ist.

Wobei ich das nicht wirklich verstehe: Selbst ÖR-HD wird "nur" mit max. 1,8 MB/s ausgestrahlt, während selbst meine langsamsten PVR-Sticks mit 10 MB/s linear beschrieben werden können.

Ganz im Gegenteil:

Besonders beim frisch gelöschten 128 GB SanDisk Extreme Go, der dann mit durchgehend 150 MB/s beschrieben werden kann (also sogar weit über dem, was die USB2-Ports der Satreceiver übertragen könnten), gibt es die meisten Probleme und nicht mal eine popelige SD-Aufnahme wird sauber aufgenommen!

Wie kann das möglich sein?

Auf den noch viel schnelleren SSDs passiert das aber nicht und lässt sich auch nicht per 2x HD+Timeshift provozieren. - Was aber auch schon die 40 GB PATA sauber schaffte, obwohl die nur mit max. 50 MB/s beschrieben werden kann und viel langsamere Zugriffszeiten hat, als selbst die langsamsten USB-Sticks.

=====================================

Ich denke, ich werde ntfs-4k/-64k erst noch auf Sticks miteinander vergleichen: Falls sich dort gravierende Unterschiede zeigen, werde ich obiges ggfs. neu bewerten.

Das habe ich heute auf einem 32 GB Platinum USB3 Stick gemacht, da der keinen übertriebenen Firlefanz wie besonders der SanDisk-Extrem-Stick hat, sondern einfach nur ein ein simpler Stick mit solider Leistung ist: Trotz Billig-Marke lässt er sich sogar mit 140 MB/s lesen und die lineare Schreibrate liegt bei dauerhaft konstanten 20 MB/s.

Das Ergebnis war überraschend (8590):

ntfs-4k:

Da eine ÖRHD-Aufnahme selbst bei zeitversetzter Wiedergabe sauber lief, habe ich noch eine 2. gestartet. Trotzdem kam es nur sehr sporadisch zu Hakern, die erst bei zusätzlich zeitversetzter Wiedergabe sehr störend wurden.

Das betraf aber hauptsächlich die Wiedergabe während der Aufnahmen: Nachdem ich beide gestoppt hatte, ließen sich beide Aufnahmen fast sauber abspielen: Nur 1-2*/Min. kam es zu einem winzigen Haker, den man kaum bemerkte.

ntfs-64k:

Zusätzlich zu zwei laufenden Aufnahmen und zeitversetzter Wiedergabe, musste ich auch noch den schnellen Bildsuchlauf nutze, damit es an der betreffenden Stelle (während weiterhin beide Aufnahmen liefen) zu einen einzigen (dafür ca. einsekündigen) Haker kam: Der die Aufnahme aber nicht betraf! Bei der alleinigen Wiedergabe lief die betreffende Stelle sauber durch.

fat32-64k:

Das fing auch erst unauffällig an, aber mit zweiter Aufnahme und zeitversetzter Wiedergabe waren die Harker nicht nur während den Aufnahmen deutlich gravierender, auch betrafen sie die Aufnahme wesentlich stärker: Selbst bei der alleinigen Wiedergabe waren die Haker so häufig, wie bei ntfs-4k mit zwei laufenden Aufnahmen und zeitversetzter Wiedergabe!

Der 8500 war schon mit nur einer ÖRHD-Aufnahme überfordert:

ntfs-4k:

Häufige und starke Aussetzer bei der Aufnahme (selbst Anzeige der Aufnahmedauer blieb ständig hängen und machte Sprünge von mehreren Sekunden) und auch die Aufnahme war anschließend vollkommen unbrachbar.

ntfs-64k:

Höchstens tendenziell "besser" als mit ntfs-4k.

fat32-64k:

Die Aufnahme hatte nur sporadische Aussetzer, aber mit Timeshift war auch das unbrauchbar.

Fazit:

Der ursprünglich sowieso nur mit FAT-Unterstützung ausgelieferte Xoro 8500 (ntfs kam erst deutlich später mit dem x. Firmware-Update) läuft unabhängig vom Datenträger mit fat32-64k deutlich am besten.

Für den 5 Jahre neueren Xoro 8590 ist ntfs-64k dagegen die beste Wahl:

Die uralte 40 GB HDD lief mit fat32-64k zwar noch etwas ruhiger, aber das war auf einer leeren, frisch formatierten Partition. - Mit der Zeit und mit größeren Belegung, würde sich das umkehren.

Also werde ich die 512 GB SSD auf ntfs-64k umformulieren, da die Vorteile auf dem Stick gravierend waren. - Für eine SSD wird das zwar nicht relevant sein, aber dann habe ich wenigstens das gute Gefühl, die bestmögliche Formatierung zu nutzen.

Leider musste ich etwas später feststellen, dass fat32 im USB-Gehäuse nicht sauber getrimmt wird (die BX500 nutzt lt. hdparm "Deterministic read ZEROs after TRIM"):

Um das zu kontrollieren, habe ich per "dd" ein Image der leeren, frisch getrimmten Partition in eine zRAM-Disk kopiert, aber obwohl es nur auf ein paar hundert KB hätte komprimiert werden dürfen, wurden es ca. 5 GB.

Auch neu formatieren und trimmen hat nichts daran geändert.

Erst als ich die SSD am SATA im PC angeschlossen und getrimmt habe, wurde das Image auf unter 200 KB komprimiert (obwohl nur lz4).

Ich habe die SSD dann noch ein paar Tage auf fat32 gelassen und als dann wieder nicht alles getrimmt wurde, habe ich auch sie auf ntfs-64k umformatiert, womit sich das nicht mehr reproduzieren ließ.

Auch jetzt noch, nach über einen Monat mit fast täglichen Aufnahmen:
Code:
/mnt/: 95,9 GiB (103009026048 Bytes) getrimmt

# dd if=/dev/sdc1 of=/tmp/zram1/bx500.raw bs=1G
103079149568 Bytes (103 GB, 96 GiB) kopiert, 333,789 s, 309 MB/s

NAME       ALGORITHM DISKSIZE DATA  COMPR MOUNTPOINT
/dev/zram1 lz4           100G  96G 618,1K /tmp/zram1
 
Zuletzt bearbeitet:
Der Thread ist ungefähr zwanzigmillionen Jahre alt: fat32 unterstützt Trim schon lange.

Intern an SATA funktioniert es ja auch, nur im USB-Gehause aus irgendeinem Grund nicht vollständig: Da ich viel mehr als nur die 5 GB aufgenommen hatte *), wurde ja getrimmt.

*) Ich nehme alles auf, was ich mir ansehen will, um die Werbepausen zu entfernen und es mir dann ansehen zu können, wann mir danach ist: Kurzfristiges wird nur geschnitten (Stream-Copy), nehme ich es auf, um es mir irgendwann mal anzusehen, oder um es zu archivieren, recode ich es, wobei ich es passend zuschneide und auch das Senderlogo entferne:

https://www.computerbase.de/forum/threads/videobearbeitung-mit-avidemux.2111091/
 
Caramon2 schrieb:
Der Thread ist ungefähr zwanzigmillionen Jahre alt: fat32 unterstützt Trim schon lange.
@Alexander2: Das hatte ich nur scherzhaft gemeint:

Ich hätte auch "uralt" schreiben können, aber das sind auch Asteroiden mit 4,5 Milliarden Jahre. Also sind "ungefähr zwanzigmillionen Jahre" ein Vielfaches präziser. ;)

Mir gefallen solche Zahlenspielereien. :)

Eine aktuelle Aufstellung, welche Dateisysteme Trim auf welcher Art unterstützen, gibt es hier: Arch-Wiki - SSDs
 
Caramon2 schrieb:
Wobei für ntfs 16k Cluster eine sinnvolle Alternative sein könnten: Das unterstützt zwar keine Datenträgerkomprimierung (nur bis 4k), aber da aktuelle SSDs lt. div. Quellen intern mit 16k Sektoren *) arbeiten, sind kleinere Cluster tendenziell kontraproduktiv.

*) Edit: mit Page-Größen (lt. Wikipedia)
Inzwischen nutze ich beide ext. SSDs mit ntfs-16k, da das offenbar die beste Clustergröße für ntfs ist:

Schon damals mit Windows XP und Samsung SATA-HDs (320 GB F1 und 160 GB P80) konnten 4k Cluster auf den großen Datenpartitionen ein großer Nachteil sein:

Das hatte ich getestet, indem ich die 160 GB frisch formatiert und die ca. 80 GB Daten wieder drauf kopiert habe. - Also bestmögliche Bedingungen.

Nach einem Reboot habe ich dann noch den TV-Browser-Odner drauf kopiert (nur ca. 20 MB, aber über 20k Dateien): Das hat mit 4k Clustern ca. 2 Min. gedauert und mit 16k Cluster nur knapp 30 Sek. - Mit 8k Cluster lag es irgendwo dazwischen und 32k/64k Cluster brachten keine weitere Verbesserung.

Auch auf der F1 haben sich später 16k Cluster als optimal gezeigt.

Zurück zu den ext. SSDs:

Der Xoro 8500 ist dabei besonders kritisch, da er offenbar keinen Datenträger-Cache nutzt und auch bei ntfs die Aufnahme alle 4 GB teilt: Damals (Ende 2010) auf einem (für die Zeit) gar nicht mal so langsamen 16 GB Medion Stick, hatte es sich mit Standardformatierung (fat32-8k - ntfs wurde erst später nachgereicht) dabei oft so "verschluckt", dass die Wiedergabe an der Stelle abbracht: Ich musste dann den genauen Zeitpunkt ermittelt und dann nach einige Sek. später springen. - Mit fat32-64k passierte das dann nicht mehr. Nicht mal bei HD-Aufnahmen.

Als ich die ext. 120 GB SSD noch mit ntfs-4k formatiert hatte, wurden beim Schnitt am PC immer mal wieder Fehler und ein paar dropped Frames angezeigt. - Mit ntfs-64k passierte das erst nicht mehr trat dann aber doch auf, nur viel seltener.

Nachdem ich die SSD aus obiger Überlegung heraus auf ntfs-16k umformatiert habe (vor ca. 3 Monaten), ist es dagegen gar nicht mehr passiert.

Also ist mein Fazit:

Wenn ntfs, dann möglichst 16k Cluster (die Datenträgerkomprimierung kann man nur bis 4k Cluster nutzen)

Wenn fat (egal ob exfat, oder fat12/16/32), dann immer 64k Cluster (s. o.)



Wenn ich es noch nutzen würde, würde ich auch Windows auf ntfs-16k installieren:

Schon weit kleinere Clusters für SSDs eher nachteilig sind, aber auch weil das bei großen Datenbeständen deutlich schneller sein kann: Wenn das schon bei einer 160 GB HD und ca. 80 GB Daten so viel ausmachen kann, dürften sehr viel größere SSDs erst recht vom geringeren Verwaltungsaufwand durch viermal weniger Cluster profitieren.

Das erreicht man, indem man das Ziellaufwerk vor der Windows-Installation partitioniert und formatiert. - Z. B. von einem Linux-Livesystem aus (das habe ich mit Windows 11 22H2 getestet - das ISO per Ventoy gebootet):
Code:
sudo -i
lw=/dev/sdX   # "X" anpassen

# Laufwerk löschen und partitionieren:
dd if=/dev/zero of=$lw oflag=direct bs=1M count=1 && blkdiscard -v $lw
sgdisk $lw -a32 -n0:1M:+239M -t1:0xEF00 -n0:0:+16M -t2:0x0C01 -n0:256M:+768M -t3:0x2700 -n0:0:0 -t4:0x0700 -p

# Partitionen formatieren:
mkdosfs $lw"1" -n  esp -F16 -s32
mkntfs  $lw"3" -QL recovery -c16384
mkntfs  $lw"4" -QL Windows  -c16384

Dabei bekommt die Windows-Partition die komplette Restkapazität des Laufwerks, wie bei einer Standardinstallation. Genauso lässt sie sich auch später verkleinern, um Platz für weitere Partitionen zu schaffen.

Da ich die Windows-Partition auf einem glatten GiB anfangen lassen wollte, habe ich die esp und recovery etwas großzügiger dimensioniert (besser mehr Platz haben und nicht brauchen, als umgekehrt ;) ): Der Win11-Installer erstellt die mit 100 MiB und 641 MiB.



Nachtrag:

Ich habe das gerade in der VM kurz durchgespielt, aufgezeichnet und das Video mit der dort genutzten sgdisk.txt angehängt.
 

Anhänge

  • Win11-mPart-Inst.mp4
    3,6 MB
  • sgdisk.txt
    sgdisk.txt
    3,6 KB · Aufrufe: 90
Zuletzt bearbeitet:
Wären deine Ausführungen zu Microsoft Dateisystemen nicht besser im Windows Forum aufgehoben?
 
@LochinSocke :

Ich nutze fat und ntfs unter Linux und auch die Windows-Partitionierung richte ich mit einem Linux-Livesystem ein. *)

Der übliche Windows-Nutzer würde sich doch gar nicht daran trauen, wie ich bei meinen Brüdern gesehen habe. - Zumindest bei denen wären das wie Perlen vor die Säue.


*) die vHD der VM hatte ich übrigens in einer zRAM-Disk, da ich Windows anschließend gleich wieder platt gemacht habe. Die unnötigen Schreibzugriffe erspare ich der SSD.
 
Zurück
Oben