Kowa schrieb:
In meinen Augen macht es keinen Sinn, eine gigabytegroße Datei in 16x mehr Cluster zu unterteilen
Die Datei sollte ja idealerweise nicht in Fragmente unterteilt sein, sondern in einem Stück vorliegen und ob die nun beim 4k großen Cluster Nummer 1.600.000 startet und die folgenden 250.000 Cluster belegt oder beim 64k Cluster 100.000 und dann 15625 nachfolgende Cluster belegt, macht für den Zugriff auf diese Datein überhaupt keinen Unterschied, denn die Größe des Clusters begrenzt ja nicht die Länge der Zugriffe auf eine Platte, zumindest nicht bei aktuellen Windowsversionen.
Kowa schrieb:
daß dies keine Auswirkung auf die Performance hat, wer solls glauben?
Probiere es doch einfach aus, dann musst Du nichts glauben. Bei einer GB großen Datei die nicht fragmentiert ist, macht es keinen Unterschied.
Kowa schrieb:
Bei SSDs sollte man sogar der Eraseblocksize entsprechen, was aber mit NFS schwierig ist. Naja, also wieso sollte man eine SSD dann nicht mit 512Byte-Clustern betreiben.
SSDs sind schon länger auf 4k lange Zugriffe die 4k Grenzen erfolgen optimiert. Bei 512 Byte pro Cluster würde dann viele Zugriffe passieren, die nicht auf 4k auf gerade 4k Grenzen erfolgen und das geht gewaltig auf die Performance. Man hat einfach die Mappingtabellen von LBAs auf Flashadressen darauf ausgelegt, dass die LBAs die Vielfache von 8 sind dort schnell gefunden werden, womit die Tabellen im Extremfall nur ein Achtel der Größe erreichen, als wenn man jeden LBA einzeln verwalten müsste und in einem flacheren Baum gehen alle Operationen eben schneller.
Werden dann wirklich mal weniger 8 LBAs überschrieben, kopiert man halt den Inhalt der übrigen einfach mit um und hat intern wieder den Inhalt von 8 aufeinanderfolgenden LBAs in einer Page liegen. Dann kann man beim Lesen wieder die untersten 3 Bits des LBAs abschneiden, die Flashadresse bestimmen, die Page mit ihrer ECC lesen, die Daten prüfen und ggf. korrigieren und dann liefert man eben nur den gewünschten Ausschnitt zurück.
Die Blocksize als Clustergröße wäre mal totaler Schwachsinn, denn das Mappen erfolgt bei allen aktuellen SSDs maximal auf der Ebene von Pages, normalweise aber auf der Ebene von 4k, da sonst die 4k Werte bei den aktuellen NANDs mit 8k oder gar 16k Pagesize zu schlecht wäre. Aber wenn, dann wählen die Pagesize als Clustergröße, wobei Du sie aber oft nicht kennst (Ok, die Blocksize auch nicht) und Dir die FW trotzdem einen Strich durch die Rechnung machen könnte, weil sie eben auf 4k optimiert ist und keiner Dir garantiert, dass sie die Daten nicht doch so über die NAND Pages verteilt, dass die Performance optimal wird und sich nicht um Deine Clustergröße schert, die sie ja gar nicht kennt.
Kowa schrieb:
Die eingesetzte Software in den Firmen ist meilenweit davon entfernt ausgereift zu sein und verursacht z.B. Tablescans. Tatsächlichen Random-Access habe ich in der freien Wildbahn sehr selten erlebt.
Da ich die SW und die Verwendung des System nicht kennen, kann ich zu deren Qualität nichts sagen, aber bei Oracle dauert ein Backup nicht so lange wie ein Full-Table Scan auf eine der mittelgroßen Tabellen, da wurde es also schon ordentlich gemacht und wenn man seine Tablespaces immer von Hand anlegt, hat man auch keine extrem fragmentierten Datafiles. Das Updates von Statistiken aber Full Table Scanns erzeugen, finde ich durchaus plausible und wenn das so oft passiert, dass es kaum Random Access auf der Platte gibt, dann habt ihr entweder sehr potente Server die die Hotdata ständig im RAM halt und fast nur Lesezugriffe darauf oder die Statistiken werden unnötig oft aktualisiert, obwohl sich der Datenbestand kaum ändert. Normal werden aber in Enterpriseumgebungen die Platten massiv mit Randomzugriffe beaufschlagt und deshalb sind die auch bei allen Enterprise Reviews von HDDs und SSDs das, was man bevorzugt bzw. fast ausschließlich testet.
Kowa schrieb:
Bei Windows stellt sich nur die Frage, wie das Filesystem den Schreibbefehl der 1,7gb-Datei an die nächst Ebene weiterreicht und meiner Meinung sind das kwrite-Systemcalls mit exakt der Cluster-Size.
Deine Ansicht interessiert Windows nicht. Suche Belege dafür und wenn Du keine findest sondern nur welch die etwas gegenteiliges aussagen, dann solltest Du Deine Ansicht mal revidieren, was man als Lernprozess bezeichnet.
(
Quelle)
(C7) 268156577052 LBAs a 512 Byte wurden geschrieben, also 137296167450624Byte = 124,8T
iB, stimmt mit den in der Quelle genannten 124.02 TiB also gut überein. Verwendet wurde dazu (C9) 4612184 Schreibbefehle, also wurden im Schnitt 29768146,2 Byte = 28,4MiB pro Befehl geschrieben. Die SSD wurde mit Anvils Benchmark beschrieben, der filesystembasiert ist und die SSDs sequentiell beschreit. Das die Clustergröße vom Standard abweichend gewählt wurden, ist
nicht erwähnt und nicht zu erwarten, zumal lesend pro Befehl nur etwa 21k gelesen wurden. Das liegt daran, dass immer wieder Metadaten vom Filesystem eingelesen (und natürlich auch geschrieben) werden und das Testprogramm die geschrieben Daten nur gelegentlich auch wieder liest um sie zu prüfen.
Aber schauen wir uns eine aus dem Forum hier an:
(
Quelle)
0x3A213566F = 15604078191 Sektoren wurden geschrieben, * 512 Byte sind das 7989288033792Byte bzw. 7,266T
iB und dazu wurden 0x12F1ACB0 = 317828272 Schreibbefehle benutzt, pro Befehl also im Schnitt 25137 Byte = 24,55kiB geschrieben.
Nächstes Beispiel auf dem gleichen Thread mit Werten ganz normaler User hier:
(
Quelle)
9168606785 Sektoren = 4694326673920 Byte mit 234537819 Befehlen ergibt hier 20015,2 Byte = 19.5kiB pro Befehl.
Wie wahrscheinlich ist es, dass diese User eine andere als die Standardeinstellung von 4k für die Cluster gewählt haben? Wenn Du meinst sehr wahrscheinlich, suche mir Gegenbeiweise die belegen, dass aktuelle Windows Systeme (also sagen wir ab XP) immer nur einen Cluster schreiben.
Kowa schrieb:
Atto legt meines Wissens eine unfragmentierte Datei an, ermittelt die physikalischen Koordinaten und schreibt dann am Filesystem vorbei.
Das ist möglich, aber AS-SSD und CDM tun das nicht.
