Na dann bestimme mal die anzahl der dateien (die größer als 1KB sind, denn die kleineren werden direkt in der sog. MFT gespeichert) und multipliziere sie mit 4095byte. Soviel ist im absoluten höchstfall der verschnitt, der im moment durch die clustergröße entsteht. Und jetzt betrachte die anzahl der cluster, die sich von ca. 25Mio auf 200Mio vergrößern. Diese ca. 175Mio extra cluster müssen irgendwo auf der platte eigene verwaltungsinformationen haben (vermutlich sogar redundant), bei FAT32 wäre das eben die FAT (und zwar i.a. doppelt also ca. 1.4GB!!! zusätzlich bzw. der maximale clusterverschnitt von ca. 360000 dateien). Bei NTFS sieht es ähnlich aus, wobei die "FAT" von NTFS nicht schon beim anlegen vollständig erstellt wird, sondern mit dem benutzten platz wächst.
Die verwaltungsdaten müssen aber auch verwaltet werden, also z.b. beim abspeichern von dateien die freien cluster suchen etc. Das geht nur, wenn diese verwaltungsdaten (ca. 800MB), zumindest teil- und zeitweise, im hauptspeicher sind. Ist schon einiges auf der platte gespeichert und hat der rechner nicht gerade hauptspeicher im überfluss, ist er nur noch damit beschäftigt, sich selbst zu verwalten und dabei wie wild zu swappen.
Viel besser wäre bei der vorliegenden nutzung die erhöhung auf die größte handhabbare (d.h. geeignet für komprimierung und defragmentierung) clustergröße. Die größte empfohlene clustergröße ist 4KB und damit genau die vorliegende.
mr.escape
mr.escape
