Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Das hat mich gewundert, weil man bisher max. 64k Cluster nutzen konnte.
Aber hier steht, dass 2 MiB Cluster schon ab Win10-1709 unterstützt werden: NTFS overview | Microsoft
Als Grund wird eine höhere Kapazität angebenden, da NTFS Cluster nur mit 32-bit adressieren kann:
NTFS can support volumes as large as 8 petabytes on Windows Server 2019 and newer and Windows 10, version 1709 and newer (older versions support up to 256 TB). Supported volume sizes are affected by the cluster size and the number of clusters. With (2^32 – 1) clusters (the maximum number of clusters that NTFS supports)
Da exFAT sogar max 32 MiB große Cluster unterstützt, frage ich mich, ob sehr große Cluster vielleicht noch andere Vorteile haben können.
Habt ihr da eine Idee?
Der Nachteil ist ja klar:
Es können nur ganze Cluster genutzt werden. Habe ich z. B. eine 100 Byte Textdatei, belegt sie einen ganzen Cluster, also bis zu 32 MiB bei exFAT. Ist Die Datei nur 1 Byte größer als ein Cluster, wird ein zweiter belegt, usw.
Besonders bei sehr vielen kleinen Dateien ist der "Schwund" dadurch enorm.
Wie du schon beim Nachteil beschrieben hast, ist der "Vorteil" genau andersrum. Wenn man wenige aber dafür große Dateien (z.B. Datenbankdatein, Sparse Files) hat, können größere Cluster etwas mehr Schreib-/Leseperformance bringen.
Bei MSSQL wird schon seit ein paar Jahren 64K Clustergröße als optimal angesehen (für Data, Temp und Log) und ich meine Oracle gibt da ähnliche Empfehlungen.
Bei der Clustergröße oder wie auch immer man die nennt geht es immer um einen Kompromiss aus Verwaltungsaufwand/Festplattengröße und Platzverschwendung.
Dabei hängt die sinnhaftigkeit einer größe von der typischerweise verwendeten Dateigrößen ab.
Wie großer echter Performanceunterschied zu erwarten ist kann ich nicht sagen, ich kenne keine aktuellen Benchmarks dazu :-)
Hast du jetzt also ne Partition oder gar ganze Festplatte, die als Videodateibunker dient, dann bieten sich größere Cluster an. Wobei ich bezweifel, das da ein Riesen Unterschied zu merken sein wird - Messbar vielleicht.
die Diskussionen darüber sind so alt wie die Dateisysteme selbst
mein erster "richtiger" Computer nach dem C64 war ein Unix Rechner mit 8 seriellen Terminal Anschlüssen und musste mit 128kB (kein Tippfehler) Speicher auskommen. Da musste das OS noch richtig mit dem RAM haushalten und jedes Byte für die Diskverwaltung hat an anderer Stelle gefehlt. Da hat man ja auch genau aus diesem Grund seinen Swap Bereich speziell formatiert.
heutzutage dürfte das eine rein Akademische Diskussion sein, die praktisch keine Relevanz hat.
RAM ist ja selbst bei Filesystemen wie ZFS kein echtes Thema mehr, wo man gleich RAID und Volumemanagement inkl. Snapshots, Copy on Write usw. ins Filesystem packt.
dazu kommt, dass auch die HDDs (die bei solchen Systemen zum Einsatz kommen) so große Caches haben (die dann im Controller per Akku gepuffert werden oder die Platten nutzen bei Stromausfall die Rotationsenergie zum flush), dass auch das regelmäßige Update der Statusinformationen auf die Platten keine Unterbrechungen (mehr) bedeutet.
wie gesagt, ich mir ziemlich sicher, dass sich da einige "Mythen" verewigt haben, die früher sicherlich mal Fakten waren, heute aber nicht mehr ganz zu modernen Systemen passen.
die Zeiten, in denen man neben dem "normalen" df auch immer nochmal geguckt hat, wie viele inodes denn noch "frei" sind, sind ja glücklicherweise auch Vergangenheit...
Wie du schon beim Nachteil beschrieben hast, ist der "Vorteil" genau andersrum. Wenn man wenige aber dafür große Dateien (z.B. Datenbankdatein, Sparse Files) hat, können größere Cluster etwas mehr Schreib-/Leseperformance bringen.
Bei MSSQL wird schon seit ein paar Jahren 64K Clustergröße als optimal angesehen (für Data, Temp und Log) und ich meine Oracle gibt da ähnliche Empfehlungen.
Bei 64k ist das noch nachvollziehbar, aber bei 2M oder gar 32M kann ich mir das nicht mehr vorstellen: Wenn z. B. ein einziger Datenbankeintrag von nur ein paar Byte geändert wird, muss der ganze Cluster neu geschrieben werden.
Alexander2 schrieb:
Bei der Clustergröße oder wie auch immer man die nennt geht es immer um einen Kompromiss aus Verwaltungsaufwand/Festplattengröße und Platzverschwendung.
Mein erster Satreceiver mit eingebauter Festplatte (40 GB PATA - vor ca. 20 Jahren) nutzte ein eigenes Dateisystem mit angeblich 160 MB Clustergröße. - Das fand ich etwas übertrieben, hatte allerdings für den Einsatzzweck keine relevanten Nachteile.
2010 habe ich mir einen HDTV-fähigen Xoro 8500 gekauft, der auf fat32 formatierten USB-Sticks aufnehmen konnte. - Da der offenenbar keinen relevanten Datenträgercache nutzte, gab es beim Start einer Aufnahme einen linearen Zusammenhang zwischen Kapazität und Clustergröße:
Z. B. dauerte es bei einem standardmäßig formatierten 16 GB Stick (8k Cluster) ca. 4 Sek., bis nach drücken der Aufnahmetaste die Aufzeichnung begann.
Mit 16k Cluster waren es noch 2 Sek., usw.
Bei einen gleich schnellen 32 GB Stick mit Standardformatierung (16k) waren es wieder 4 Sek., usw.
Die Clustergröße selbst war dabei also egal, es zählte offenbar einzig die Anzahl der Cluster: bei 16 GB mit 8k waren es gleich viele, wie bei 32 GB mit 16k. -Das hatte ich auch auf den Verwaltungsaufwand geschoben.
Später wurde übrigens ntfs nachgereicht, aber auf USB-Sticks war fat32-64k deutlich besser: HDTV-Aufnahmen bekamen mit ntfs-4k *) haufenweise Haker und Aussetzer, obwohl nur max 1,8 MB/s, der Stick aber eine lineare Schreibgeschwindigkeit von 10 MB/s schaffte.
*) mit größeren Clustern wurde es eher schlimmer
exFAT kann ich leider nicht testen, da er das nicht unterstützen.
s.o.
USB Stick: kein lokaler Cache, Verwaltung mit wenig RAM auf "kann jederzeit abgezogen werden" optimiert.
genau das sind eben die "Randbedingungen", unter denen man sich, wenn es um Petabyte geht, eben NICHT herum schlagen muss und diesbezügliche Erfahrungen auch nicht wirklich übertragen werden können/sollten.
Ich wollte damit zeigen, dass unter solch primitiven Umständen die Clustergröße einen großen Einfluss haben kann: Dass ging sogar so weit, dass der Satreceiver sich bei zu kleinen Clustern, sich währende der Aufnahme, beim anlegen der nächsten 4 GB Datei, "verschluckt" hat und die Wiedergabe an der Stelle abbrach: Ich musste die Stelle dann per direkter Zeiteingabe überspringen.
Meine ursprüngliche Frage betrifft natürlich aktuelle Technik (PCs, Serverfarmen, usw.), ob die selbst ohne entsprechend große Plattenkapazität, die 2M (ntfs) oder 32M (exfat) Cluster bedingt, unter irgendetwelchen Umständen Vorteile daraus ziehen könnte.
Bei exfat (RAM-Disk → SSD) hatte ich das mal mit einer mehrere GB großen Datei getestet (sync;time cp -av … ;time sync), da wurde es über 64k aber kaum noch schneller (homöopathisch) und ab 1M Cluster sogar wieder langsamer. - Da war exfat aber noch fuse.
Das werde ich bei Gelegenheit nochmal testen und ntfs-4k vs -64k vs.-1M vs. -2M (mit ntfs3) dann auch.
Auf der MX500 sind ca. 87 GiB belegt (20 GB Linux- + 160 GB Home-Partition): Beide Partitionen hatte ich frisch getrimmt und anschließend ausgehängt.
Der Test fand auf der leeren 53 GiB Partition am Ende statt, die ich jedes Mal zuerst per "blkdiscard" gelöscht, dann formatiert und anschließend mehrere Min. in Ruhe gelassen habe.
Die Dauer für "cp" und "fstrim" habe ich zusammengezählt.
Die genutzten Befehle:
("dd" in /tmp/ ausgeführt, das ich per fstab mit tmpfs (=im RAM) gemountet habe)
Code:
dd if=/dev/urandom of=rnd bs=1G count=2
gov p # CPU auf "performance" (s. u.)
sync;blkdiscard -fv /dev/sda3
mkfs.exfat /dev/sda3 -L Test -c16k
mkfs.ntfs /dev/sda3 -QIL Test -c2097152
mkfs.xfs /dev/sda3 -L Test
sync;time cp -a rnd /run/media/user/Test/;time sync
Überraschenderweise lässt sich exfat endlich trimmen. Darauf warte ich schon, solange ich SSDs nutze. (Ende 2015)
Zuletzt habe ich es vor einigen Monaten getestet, als exfat ja schon lange im Kernel war, aber da funktionierte es noch immer nicht.
Hier mein "gov"-Skript:
(mit AMD K8 bis FX-8350 getestet, aber sollte generell nichts kaputt machen können, da es nur die Nutzung der Standardtaktstufen beeinflusst)
Code:
#!/bin/bash
if [ -z $1 ]
then cat /sys/devices/system/cpu/cpufreq/policy0/s*{gov*,_*a*freq*}
exit;fi
if [ ! -z $2 ];then t=$2
for g in /sys/devices/system/cpu/cpufreq/policy*/scaling_max_freq
do echo $((t*10**5))|sudo tee $g >/dev/null
done;fi
case "$1" in
p)
for g in /sys/devices/system/cpu/cpufreq/policy*/scaling_governor
do echo performance|sudo tee $g >/dev/null
done
;;
s)
for g in /sys/devices/system/cpu/cpufreq/policy*/scaling_governor
do echo powersave|sudo tee $g >/dev/null
done
;;
u)
for g in /sys/devices/system/cpu/cpufreq/policy*/scaling_governor
do echo schedutil|sudo tee $g >/dev/null
done
;;
*) if [ -z $2 ];then echo "gov p/s/u [Takt] <- (p)erformance / power(s)ave / sched(u)til";exit;fi
;;
esac
cat /sys/devices/system/cpu/cpufreq/policy0/scaling_{governor,max_freq}
Ohne Parameter aufgerufen, zeigt es die aktuellen Einstellungen und Möglichkeiten an und mit nur einem Parameter eine Kurzanleitung:
1. bedeutet, das "schedutil" und max. 4 GHz eingestellt sind.
Da ich in einer Dachwohnung wohne, limitiere ich im Hochsommer (bei längerer hoher CPU-Auslastung: z. B. Videoencoding) den max. Takt z. B. mit "gov t 28" auf 2,8 GHz (egal was man übergibt, es wird immer aus die nächste Möglichkeit abgerundet), oder lasse ihn mit "gov s" nur mit Idletakt takten.
Das lässt sich auf kombinieren. Z. B. mit "gov p 34" lasse ich ihn mit max. Takt takten, limitiere den aber auf 3,4 GHz.
Nur, weil die für Dich anscheinend "am Ende" der SSD hängt, muss das physikalisch nicht der Fall sein. Bekanntlich mappt die SSD ihre Sektoren bei Bedarf (und zwar auch, ohne dass defekte Sektoren ersetzt werden müssen) kreuz und quer über die phys. Flash-Speicher.
Wie und in welcher Größe die SSD dann intern die Sektoren verwaltet, muss man vermutlich erst einmal heraus finden. Immerhin hat die MX500 einen DRAM-Cache, was sie aber trotzdem mit Pech nicht daran hindert, einen logischen Sektor auf X phys. nicht zusammenhängende Blöcke und u.,U. (naja, bei der keinen 250 GB SSD vermutlich nicht) auf mehrere Flash-Chips aufzuteilen.
Dazu kommen mit Pech noch SW-Optimierungen der Übertragungsfunktionen auf gewisse Blockgrößen.
Caramon2 schrieb:
Überraschenderweise lässt sich exfat endlich trimmen. Darauf warte ich schon, solange ich SSDs nutze.
Welchen Sinn/Mehrwert hat exFAT bei der Nutzung auf internen Datenträgern? Selbst bei ext. Datenträgern vermeide ich es, wo es nur geht, also immer dann, wenn die Kamera es nicht zwnagsweise nutzt. Mag aber sein, das der Linux exFAT Trieber um Lichtjahre besser ist wie der von Windows. MS nutzt dort bis heute eine steinzeitliche Ungenauigkeit von 2 Sekunden für die Zeitstempel, womit das ganze unbrauchbar ist, wenn man irgnedwas auf Basis der Zeitstempel synchronisieren will.
Wie und in welcher Größe die SSD dann intern die Sektoren verwaltet, muss man vermutlich erst einmal heraus finden. Immerhin hat die MX500 einen DRAM-Cache
Dass es intern sonst wo geschrieben werden kann, ist mir klar und auch, dass die Position bzgl. der Geschwindigkeit belanglos ist.
Ich wollte damit nur die Partitionierung veranschaulichen: Zuerst 20 GiB, dann 160 GiB und über den kompletten unpartitionierten Rest von knapp 53 GiB eben die Testpartition.
DRAM-Cache ist bei sowas nahezu egal, wie ich damals hier gezeigt habe:
Von exfat halte ich auch nichts, aber damals dachte ich noch, da es einen geringeren Overhead als ntfs hat, müsste es beim simplen kopieren großer Dateien (konkret Videoschnitt: reines Streamcopy) doch eigentlich schneller sein.
Inzwischen weiß ich es zwar besser, trotzdem hat es mich gestört, dass man ein angeblich extra für Flash-Speicher optimiertes Dateisystem, selbst nach Jahren und offiziellen Support, immer noch nicht trimmen konnte.
Da sehr große Cluster sogar langsamer sind (s. o.), braucht man die wirklich nur für entsprechend rieseige Kapazitäten? - Nichts was vielleicht doch davon profitieren könnte?
Zur Info:
Ich habe mich heute in exFAT etwas eingelesen und dazu das im Bekanntenkreis verschickt:
The standard exFAT implementation is not journaled and only uses a single file allocation table and free-space map. FAT file systems instead used alternating tables, as this allowed recovery of the file system if the media was ejected during a write (which occurs frequently in practice with removable media).
Das meinte ich damit, dass exFAT noch unsicherer als FAT ist.
This is achieved through the introduction of a separate cluster bitmap where the reservation state of each cluster (reserved/free) is tracked by only one bit, reducing writes to the much larger FAT that originally served this purpose.
Linux has support for exFAT via FUSE since 2009. [4] In 2013, Samsung Electronics published a Linux driver for exFAT under GPL .[31] On 28 August 2019, Microsoft published the exFAT specification [6] and released the patent to the Open Invention Network members.[32] The Linux kernel introduced native exFAT support with the 5.4 release in November 2019. [33]
Wenn man auf FAT z. B. eine leere 1 GiB Datei erstellen will (z. B. eine casper-rw für ein Ubuntu-Livesystem), müssen tatsächlich 1 GiB geschrieben werden.
Da steht u. a. dass ein Feature erst mit Kernel 5.7 eingeführt wurde (ich hatte mich oben also korrekt erinnert) und dass Trim mit dem 5.13 (Sommer 2021) eingeführt wurde. - Das kommt mir espaniol vor, da ich meine, ich hätte das erst vor einigen Monaten mal wieder ausprobiert und da funktionierte Trim definitiv noch nicht: Das war mindestens der 5.15, in dem ntfs3 endlich integriert wurde (vorher hatte ich es aus dem AUR nachinstalliert) und im Zuge dessen hatte ich auch wieder versucht, exfat zu trimmen.
exFAT unterstützt weder Hard-, noch Softlinks (im Gegensatz zu ntfs). Es kann weder vergrößert, noch verkleinert werden (im Gegensatz zu ntfs). Außerdem unterstützt es keine sparse Dateien (im Gegensatz zu ntfs).
Dafür lässt es sich unter Linux prüfen und reparieren (im Gegensatz zu ntfs) und fstrim funktioniert jetzt auch (im Gegensatz zu ntfs3 <- ntfs-3g ist bei meinen Einsatzzweck viel zu langsam).
Also habe ich meine Videoschnitt-Partition auf der int. SSD jetzt doch mit exFAT (64k Cluster) formatiert: Dabei ist es gegenüber ntfs nur geringfügig langsamer: 125 statt 121 Sek. für einen ÖR-HD-Spielfilm.
Ich kenne weder den Controlller noch den Flash-Aufbau so gut um entscheiden zu können, ob der Controller einen zusammenhängenden 64k Cluster aus 16 4k Sektoren, die in einer phys. Speicherzelle liegen, genauso schnell lesen kann wie wenn diese 16 phys. Sektoren wild über den gesamten Flash speicher verteilt sind. U.U. sorgt der Controller beim Schreiben aber auch dafür, dass die Sektoren eines logischen Sektors von z.B. 64k immer und ewig am Stück geschrieben werden. Völlig egal, welche Clustergröße die anderen Partitionen genutzt haben.
Caramon2 schrieb:
Nichts was vielleicht doch davon profitieren könnte?
Ohne noch hunderte Tests mit Deinen spezifische Anwendungen zu machen, nicht. Ich bin da sowieso raus, da ich Performance-Tests bisher nur unter Windows gemacht habe.
Ich komme aber auch, Dank fehlendem Dual-Systembetrieb am PC, nicht auf die Idee, intern ein Filesystme zu nutzen, das nicht zu den nativen des OS gehört (also für mich NTFS unter Windows und EXT3/4 oder BTRFS unter Linux). Seit meinem Chaos mit den Zeitstempeln bei exFAT ist meine ext. SSD auf NTFS umformatiert und exFAT wird nur noch für Speicherkarten meiner Kamera genutzt (die diese dann aber nach ihren Wünschen selber formatiert).
exFAT käme u.U. wieder zum Einsatz, wenn ich neben Windows und Linux auch noch MacOS nutzen sollte.
Was ein Filesystem mit der SSD veranstaltet, ist mir völlig egal. Keine meiner SSDs wir jemals an die (versprochene) Schreibleistung kommen, falls der SSD-Controller nicht falsch zählt. Solche Kopier/Schneideaktionen laufen bei mir vollständig in der dyn. 50 GB Ramdisk, wenn die Filme mal die SSD vom (Linux-)Receiver verlassen sollten. Der dürfte mit EXT3 formatieren und wenn die SSD dort irgendwann kaputt geht, gibt es halt eine neue. 6,5 Jahre hat sie meine Nutzung schon ausgehalten, davon 2,5 Jahre im 24/7 Betrieb.
Bei (recht vollen) HDDs und passender Verwaltung im Filesystme könnte die Performance durchaus von größeren Clustern profizieren, da diese dann garantiert unfragmentiert wären. Und sonst hilft es halt gege Deine Angst, dass ein Dateisysten die SSD mit Verwaltungstätigkeiten kaputt schreiben könnte.
Caramon2 schrieb:
Das meinte ich damit, dass exFAT noch unsicherer als FAT ist.
Ohne zu wissen, wie der Test und der FS-Treiber intern funktioniert (lesen beide überhaupt >64K am Stück von der SSD oder wird das spätestens im FS-Treiber auf 64 KB herunter gebrochen) bleiben solche Tests für mich Spekulation. Ich bin auch schon zu faul im Netz zu suchen, ob SATA (und/oder NVMe) überhaupt Blöcke >64KB am Stück lesen/übertragen können.
Caramon2 schrieb:
Wenn man auf FAT z. B. eine leere 1 GiB Datei erstellen will (z. B. eine casper-rw für ein Ubuntu-Livesystem), müssen tatsächlich 1 GiB geschrieben werden.
Mag sein, mit FAT32 habe ich mich seit ca. 20 Jahren (muss wohl Win 98SE und das parallel intsalliert Linux gewesen sein) nicht mehr herum geschlagen (Speicherkarten von Digitalkameras und Autoradios mal ausgenommen).
Dafür lässt es sich unter Linux prüfen und reparieren (im Gegensatz zu ntfs) und fstrim funktioniert jetzt auch (im Gegensatz zu ntfs3 <- ntfs-3g ist bei meinen Einsatzzweck viel zu langsam).
bei Gentoo linux gibt es den Command ntfsfix - damit darf ich regelmässig die von Windows 10 Pro zerstörten NTFS physical extents reparieren. Windows 10 Pro wird selbstverständlich ordnungsgemäß heruntergefahren. Da meine source files und anderer Junk auf ntfs liegen - darf ich dies regelmässig reparieren.
Ich verstehe den Rant gegen Kernel Fuse module auch nicht. Kernel 5.4 ist Steinzeit.
Das(s) man Fuse Module für NTFS nachladen muss vom Userspace ist klar.
Der Kernel integrierte NTFS Modul ist recht brauchbar - habe bis vor einem halben Jahr ntfs3g benutzt.
Ich würde eher getestete Sachen nehmen wie NTFS oder EXT4.
Ich bin leider wegen UEFI bzw. Windows 10 Pro gezwungen einen Teil auf FAT32 zu verwenden!
Kein Exfat, BTRFS, XFS, Reiserfs und sonstige Exoten.
Ergänzung ()
Caramon2 schrieb:
Es können nur ganze Cluster genutzt werden. Habe ich z. B. eine 100 Byte Textdatei, belegt sie einen ganzen Cluster, also bis zu 32 MiB bei exFAT. Ist Die Datei nur 1 Byte größer als ein Cluster, wird ein zweiter belegt, usw.
Besonders bei sehr vielen kleinen Dateien ist der "Schwund" dadurch enorm.
Das ist es jedenfalls nicht, diese Tabelle (FileTable) hat jedes Dateisystem, we eben abgescpeichert wird wo die eigentlichen Daten zu Datei X/Y oder Ordner abgelegt sind auf dem Physischen Medium.
Sorry, ich habe mich momentan etwas verzettelt, deshalb nur kurz:
Kleine Dateien speichert NTFS (offenbar bis zu einem gewissen Grad) im MFT. Das spart aber keinen Platz (weiterhin ein Cluster pro kleine Datei), sondern soll die Fragmentierung reduzieren.
Kein Problem, vielen Dank für deine Antwort. Das Speichern von kleinen Dateien im MFT ist tatsächlich eine Methode, um die Fragmentierung zu reduzieren. Da der MFT ein reservierter Bereich auf der Festplatte ist, können die kleinen Dateien direkt dort gespeichert werden, ohne dass ein eigener Cluster zugewiesen werden muss. Allerdings ist dies auch kein Allheilmittel, da der MFT selbst fragmentiert werden kann und somit die Performance wiederum beeinträchtigt wird. Es ist daher wichtig, verschiedene Methoden zur Reduzierung der Fragmentierung zu kombinieren, um optimale Ergebnisse zu erzielen.
Das "verzetteln" liegt zum Teil übrigens an diesem Thread: Ich habe fat32-64k, ntfs-4k und ntfs-64k auf Stick und SSD an meinem Satreceiver getestet (dazu schreibe ich noch). Außerdem hatte ich mir neue SSDs gekauft, die mussten auch erst mal getestet werden.
Lora schrieb:
Das Speichern von kleinen Dateien im MFT ist tatsächlich eine Methode, um die Fragmentierung zu reduzieren. Da der MFT ein reservierter Bereich auf der Festplatte ist, können die kleinen Dateien direkt dort gespeichert werden, ohne dass ein eigener Cluster zugewiesen werden muss.
Stimmt. Was ich oben geschrieben habe, dass trotzdem jede Datei einen Cluster belegt, ist offenbar falsch:
Um es auszuprobieren, habe ich Win11-22H2 (als Pro for Workstations) in einer VM installiert und eine 176 GiB Partition mit ntfs-2M formatiert: (die Shots habe ich der Größe wegen ohne Dithering auf 256 Farben reduziert)
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:
Ich habe dann ein Artixlinux-Livesystem gebootet und da es auf der Partition nur ca. 90k Cluster gab, 2^16 Testdateien in einem Unterverzeichnis erstellt:
Code:
for ((z=1;z<=65536;z++));do echo $z>$z;done
Das hat übrigens über 2 Min. gedauert!
Zum Vergleich auf xfs:
Code:
$ sync;time for ((z=1;z<=65536;z++));do echo $z>$z;done;time sync
real 0m2,600s
user 0m0,711s
sys 0m1,872s
real 0m1,174s
user 0m0,000s
sys 0m0,003s
Anschließend wieder in Windows:
Dort belegten die 373 kiB Daten "nur" 88 MiB (statt 2^16*2 MiB, wenn wirklich jede Datei einen Cluster belegen würde):
Dort hat mich "Größe auf Datenträger: 0 Bytes" irritiert: 376 kiB groß, 88 MiB mehr belegt!
Diesmal habe ich das Administrator-Terminal nicht per Rechtsklick-Menü von der Taskleiste aus geöffnet, sondern übers Suchfeld des Startmenüs (mit "cmd" und Strg+Shift+Enter), da dann "dir /a" funktioniert und die Schrift auch nicht übergroß ist:
chkdsk zeigte keine Auffälligkeiten:
Dann wollte ich den "Programm Files" Ordner nach D:\ kopieren, um zu sehen, wie viel der dort belegt, aber auch dabei hat Windows wieder Probleme gemacht:
Da ich erst mal wieder die Schnauze voll von Windows hatte (was hat mich dieser elende Dreck schon an Nerven gekostet…), habe ich es anschließend platt gemacht.
Ich bin so froh, schon seit Jahren nicht mehr darauf angewiesen zu sein.
Ergänzung ()
_roman_ schrieb:
Caramon2 schrieb:
Dafür lässt es sich unter Linux prüfen und reparieren (im Gegensatz zu ntfs) und fstrim funktioniert jetzt auch (im Gegensatz zu ntfs3 <- ntfs-3g ist bei meinen Einsatzzweck viel zu langsam).
bei Gentoo linux gibt es den Command ntfsfix - damit darf ich regelmässig die von Windows 10 Pro zerstörten NTFS physical extents reparieren. Windows 10 Pro wird selbstverständlich ordnungsgemäß heruntergefahren. Da meine source files und anderer Junk auf ntfs liegen - darf ich dies regelmässig reparieren.
"ntfsfix" ist nichts spezielles, sondren gehört generell zu ntfs-3g. Es ist kein chkdsk-Ersatz, sondern kann ntfs nur soweit wieder hinbiegen, dass Windows es mit chkdsk prüfen kann: Es wird ein Flag gesetzt, wodurch Windows das beim booten automatisch macht. Davon bekommt man nichts mit.
Solange du bei Windows den Quickstart nicht deaktiviert hast, wird es nicht "ordnungsgemäß heruntergefahren". - s. "man ntfs-3g":
Windows hibernation and fast restarting
On computers which can be dual-booted into Windows or Linux, Windows has to be fully shut
down before booting into Linux, otherwise the NTFS file systems on internal disks may be
left in an inconsistent state and changes made by Linux may be ignored by Windows.
So, Windows may not be left in hibernation when starting Linux, in order to avoid incon‐
sistencies. Moreover, the fast restart feature available on recent Windows systems has to
be disabled. This can be achieved by issuing as an Administrator the Windows command which
disables both hibernation and fast restarting :
Von ext4 halte ich aufgrund div. Erfahrungen nichts mehr und MS-Dateisysteme taugen IMO alle nicht viel.
Reiser war quasi schon tot, als ich 2015 auf Linux umgestiegen bin (ich habe noch nie davon gelesen, dass irgendjemand das nutzt), aber damit xfs als Exoten zu bezeichnen, machst du dich meiner Meinung nach lächerlich.
