welche clustergröße bei ntfs&500gb?

[vulgo]

hallo!
man kann ja auch bei NTFS die clustergröße auswählen und ich will nun auf meiner 500gb zwei partitionen
*1 zweitwindows, falls das erste macken macht (die 20gb sollten kein platzproblem darstellen )
*2 der rest ist NUR für dateien mit 3-10mb und ~1-7gb größe (+sysbkps, die aber wohl nur aus einer datei bestehen dürften)

-> welche größe wähl ich am besten für *2 aus?

 

[HisN]

Warum willst Du eine andere Clustergröße als die vom System vorgeschlagene nehmen? Was soll Dir das bringen? Geschwindigkeit? Ich denke nicht das Dein Sysbackup-Tool HDD-Limitiert ist sondern eher CPU-Limitiert sein wird.

 

[vulgo]

weil ich nur große dateien verwende. (das mit dem bkp ist nebensächlich) eben 3-10mb groß und 1-7gb.
Je größer die Cluster sind, desto weniger Verwaltungsaufwand muss für große Dateien aufgewendet werden und desto geringer wird die statistische Fragmentierung einer Datei. von der halbzuverlässigen quelle wikipedia.
und den windowsvorschlag 'standard' empfinde ich als unzureichend informativ.

 

[hasugoon]

*1 4kbyte
*2 32kbyte

 

[vulgo]

524288000kb sinds gesammt
bei 20gb =20971520 bei 4kb großen cluster sind das 5242880 bei 64kb nur 327680 cluster die verwaltet werden müssen.

ich überlege mir das nämlich ca wie von csa evil vorgeschlagen zu machen (danke für deinen vorschlag )
*1 mit 4kb (oder2kb)
*2 mit 32 oder 64kb

zu *1
da dateien kleiner 1kb ohnehin in der mft gespeichert werden, eben meine überlegung mit 2kb, weil ich auf C
12000 dateien mit 0-1kb
und 8500 mit 1-4kb habe

 

[HisN]

Nochmal die Frage, was versprichst Du Dir von "weniger Verwaltungsaufwand"?
Prökeln im Promille-Bereich :-)

 

[Simpson474]

@HisN: Wieso sollte er keine größeren Cluster verwenden, wenn er nur größere Dateien auf der Partition sichert? Auf die Performance wird sich das zwar nicht großartig auswirken, wenn man aber die geringere Fragmentierung dazu rechnet, dann kann da schon ganz schön was dabei rauskommen. Denn mit 32kb kann die Festplatte selbst bei einer 100% fragmentierten Datei noch 32kb sequentiell (also mit ca. 65MB/s) lesen, bevor der Lese-Kopf neu positioniert werden muss. Verwendet er jedoch nur 4kb Cluster, dann muss bei einer 100% fragmentierten Datei der Lesekopf 8x öfter neu positioniert werden.

 

[vulgo]

@hisn
weniger vergeudeten speicherplatz. -die fragmentierung ist mir nciht so wichtig, bleiben die doch eher unverändert drauf bzw. die großen (mehere gb) ändern sich häufiger.

aber mal andersrum: warum sollte ich kleine clustergrößen verwenden?

 

[hasugoon]

damit mehr auf die winzige 500gb platte passt

 

[HisN]

fjmi
Wus?
Wenn Du 4KB-Cluster hast und eine x-GB-Datei speicherst, dann hast Du maximal 3KB "Verlust"
Wenn Du 32KB-Cluster hast und eine x-GB-Datei speicherst, dann hast Du maximal 31KB "Verlust"
Würde sich bei Deinem Anwendungs-Gebiet sowieso in Grenzen halten, so viele GB-Dateien passen ja nicht auf die kleine Platte.
Oder sehe ich das irgendwie falsch. Ich lass mich da ja gerne eines besseren belehren.

 

[vulgo]

ich lass mich ja gerne überzeugen, dass die 4kb die beste lösung sind, aber dann wüsste ich halt schon gerne warum
@hisn (nicht dieser verbrauch, sondern der verbrauch der verwaltung der cluster )
bei 10 000 dateien mit 5mb (=5120kb) sind das bei 4kb bei 12.800.000 cluster
bei 32kb 'nur' 1.600.000 und bei 64kb 800.000.
und dass die 12 mio mehr 'nichts' ausmachen, kann ich mir nicht vorstellen.

 

[Simpson474]

Das mit dem geringeren Verlust von 4kb stimmt schon, aber es müssen eben auch 8x mehr Cluster gespeichert werden, die auch wieder Speicherplatz verbrauchen.

 

[HisN]

Ach ihr meint den winzigen Teil der Festplatte in dem die MFT gespeichert ist? Das ist ne Bitmap die sagt "belegt" oder "frei" und die kann nicht gerade groß sein^^.

Wie schon anfangs gesagt, das ist echt Prökeln im Promille-Bereich :-) Ich frag mich immer warum ihr das besser als "MS" machen wollt. Ist wie mitm Auto, die Ingineure die den Motor gebaut haben werden schon wissen ob ich Super oder Normal tanken muss.

Der "Verwaltungs-Aufwand" besteht doch nur darin, das in der MFT nach dem Speichern der Datei die entsprechenden Cluster als "belegt" markiert werden. Ansonsten muss das Filesystem doch auch von Cluster zu Cluster springen beim Schreiben oder Lesen, ich glaub
a) nicht dass das auffällt
b) nicht da es Leistung frisst
c) das Deine Anwendung davon Profitieren wird.

ABER ... ich kann leider keine technisch fundierte Erklärung abgeben *duck*

 

[vulgo]

~120mio bits eben bzw. 8mio. die verwaltung kann doch nicht gleich 'einfach' sein, oder doch?

 

[Simpson474]

Zumindest bei FAT wurde noch in jedem Cluster gespeichert, in welchem Cluster die Datei fortgeführt wird. Das sind zwar dann bei 32Bit-Adressraum auch nur 4 Byte pro Cluster, deshalb sollte speicherplatzmäßig bei großen Dateien zwischen 4kb Clustern und 32kb Clustern kaum ein Unterschied sein. Der größte Vorteil ist eben die höhere Geschwindigkeit, die durchaus (je nach Fragmentierung) in den zweistelligen Prozentbereich gehen kann.

 

[HisN]

DAS würde ich gerne mal mit der Stoppuhr nachmessen :-)

 

[vulgo]

und DAS habe ich eben die letzte zeit gemacht
einziges manko: das quelldateisystem ist ntfs mit 4kb cluster -da aber alle meine übrigen diese größe haben zählt das für mich als zulässig.
kopiert wurde von einem anderen laufwerk (schnell genug )
und interessanterweise gibts folgenden sachverhalt:

5,31gb große datei
bei 4kb 1min 08sec
bei 64kb 1min 11sec

19,1gb
bei 4kb 4min 49sec
bei 64kb 5min 0sec


-> also erscheint mir die standardclustergröße (sofern diese 4kb ist) als besser geeignet

 

[HisN]

Nice Try.
Fein dass Du Dir die Mühe gemacht hast anstatt das noch weiter auszuquatschen :-)