Bis neue HDDs mit noch größeren Sektoren auf den Markt kommen. Oder glaubt ihr ernsthaft das es das war?
Doch, ich denke schon. Native 4K-Laufwerke werden kommen (wenn gewisse Betriebssysteme endlich damit umgehen können), dann wars das. Der Wechsel auf 4K kam ja unter anderem, weil man seit längerer Zeit im Normalfall 4K als untere Grenze der Clustergröße in Dateisystemen benutzt. Je nach Anwendung auch mehr, aber eben kaum weniger. Datenbanken nutzen scheinbar 8K. Kleine Dateien werden aber immer klein bleiben*.
Und weil die Checksummenbildung und insbesondere die Fehlerkorrektur auch bei 4K-Blöcken noch anständig funktioniert. Je größer der ECC-Block, desto besser kann man Bitfehler korrigieren, aber desto aufwändiger wird die Sache ja auch. Bisher musste man mit 50 Bytes 512 Bytes an Daten rekonstruieren. Neuerdings muss man aus 100 Bytes 4096 Bytes wieder zusammenflicken. Wies wohl wird, wenn man mit 200 Bytes 16384 Bytes rekonstruieren soll? Ich bin kein Mathematiker, aber die Komplexität steigt da sicherlich nicht linear...damit haste noch höhere Latenzen und entsprechenden Bedarf an Rechenleistung auf der Platine. Manche Platten zeigen ja reale ECC-Korrekturen an, und die gehen bei Transfers von n paar hundert GB auch mal schnell in die Milliarden Stück. Bei 512B-Sektoren wohlgemerkt.
Die Platzersparnis auf dem Platter ist sicherlich willkommen, schrumpft mit immer größeren Sektoren aber zunehmend zusammen. 512B->4096B hat da noch schick was gebracht, aber 4K->?K wirds nicht mehr rausreißen. Was würdest du denn vorschlagen? 8K? Kleiner Hüpfer, wird man wohl nicht machen. 16K? Denkbar, vielleicht Gleichstand mit künftiger Pagesize von SSDs. 32K wären ein Kandidat. 64K sind schon jenseits der maximalen Clustergröße von FAT32 und älterer NTFS-Versionen. 128K reißt auch neueres NTFS. Und weils hier ja um ZFS geht wollen wir mal nicht untern Tisch kehren, dass da auch vernünftige Stripesizes rausspringen müssen. Minimal muss die Stripesize ja der Clustergröße entsprechen, und jene soll nicht unter der physikalischen Sektorgröße liegen. Macht eine immer höhere Anzahl kleinerer Daten, die überhaupt nicht auf mehrere Platten verteilt werden, bzw. durch entsprechende Einstellung einfach dupliziert werden, also Mirroring statt Z1/2/3. Das ist auch nicht Sinn der Sache und hebt manchen Vorteil von ZFS einfach auf.
*Mal n Zahlenspiel: Ich als Linuxer hab auf /, exklusive /home, /proc und /dev, 600.644 Files und 63117 Ordner liegen, Gesamtgröße läppische 25,8 GiB für mein Gesamtsystem. Das macht pro Datei 45,0 KiB. Bei 32K-Clustern hätt ich damit pro zwei belegter Cluster einen halben als Verschnitt. Alleine das ist schon ziemlicher Wahnsinn und hebt jeden Speicherplatzgewinn durch bessere Platterausnutzung auf. Klar, ich kann mit kleineren Clustern als physikalisch vorhanden partitionieren. Drückt die Performance halt entsprechend. In der Rechnung ist aber gar nicht mit drin, dass der Großteil der Datenmenge in ganz wenigen Dateien vorhanden sind. Die 55 Dateien oberhalb von 50 MB machen alleine ~8,0 GiB aus. Drückt die restliche durchschnittliche Größe auf 31,0KiB. Damit wäre die durchschnittliche Dateigröße kleiner als die Sektorgröße. Geile Sache - denn alles was drunter liegt braucht trotzdem 32K, egal wie klein, und alles drüber braucht mindestens 64K. Das bläst mir den vermeintlichen Platzverbrauch auch wieder enorm auf.
Aus Windowssicht isses nicht besser, XP war noch kompakt, Vista/7 verfolgen aber ebenfalls die Zersplitterungsstrategie. Wenn du eins zur Hand hast, schau dir doch mal die Eigenschaften des Systemordners an. Ggf. mit Tools wie jdiskreport, die sortieren das nämlich gleich mal hübsch:
Ubuntu:
Code:
Distribution of sizes in /
Size Interval Sum of File Sizes (KB) % of Total Files % of Files
Over 16 GB 0 0,0% 0 0,0%
4 GB – 16 GB 0 0,0% 0 0,0%
1 GB – 4 GB 0 0,0% 0 0,0%
256 MB – 1 GB 1.236.042 4,5% 2 0,0%
64 MB – 256 MB 3.177.712 11,6% 35 0,0%
16 MB – 64 MB 4.866.759 17,8% 156 0,0%
4 MB – 16 MB 4.871.858 17,8% 648 0,1%
1 MB – 4 MB 3.689.495 13,5% 1.874 0,3%
256 KB – 1 MB 3.635.312 13,3% 7.610 1,3%
64 KB – 256 KB 2.829.488 10,4% 23.268 4,0%
16 KB – 64 KB 1.727.845 6,3% 55.749 9,5%
4 KB – 16 KB 892.246 3,3% 105.531 18,1%
1 KB – 4 KB 327.032 1,2% 156.206 26,7%
0 KB – 1 KB 64.255 0,2% 233.361 39,9%
67% aller Files (389k!) haben also 4K oder weniger...
Windows:
Code:
Distribution of sizes in /media/root/tx64
Size Interval Sum of File Sizes (KB) % of Total Files % of Files
Over 16 GB 0 0,0% 0 0,0%
4 GB – 16 GB 0 0,0% 0 0,0%
1 GB – 4 GB 2.097.152 9,7% 1 0,0%
256 MB – 1 GB 0 0,0% 0 0,0%
64 MB – 256 MB 713.248 3,3% 5 0,0%
16 MB – 64 MB 2.323.233 10,8% 84 0,1%
4 MB – 16 MB 5.685.345 26,4% 772 0,9%
1 MB – 4 MB 4.957.933 23,0% 2.590 2,9%
256 KB – 1 MB 3.331.815 15,5% 6.498 7,2%
64 KB – 256 KB 1.637.234 7,6% 13.086 14,6%
16 KB – 64 KB 578.356 2,7% 16.841 18,8%
4 KB – 16 KB 152.791 0,7% 17.638 19,7%
1 KB – 4 KB 52.626 0,2% 23.106 25,8%
0 KB – 1 KB 4.392 0,0% 9.090 10,1%
Klar, dann kann man wieder mit Spielchen anfangen wie Kleinstdateien in den MFT-Bereich zu schieben, oder Inodes mit Datenanhängseln aufzublasen, oder...
Meinen Pool ist noch mit ashift=9 daran hatte ich gar nicht gedacht.
Nachdem die HD204UI schon 4K-Laufwerke sind, ist der Pool vermutlich von vorn herein schon falsch angelegt worden. Blöd, dass es jetzt mit Laufwerken, die sich identisch verhalten, nicht mehr weiter geht
Ich würd dir ja ne HD203WI im Austausch anbieten, aber bis mein System steht wirds noch mindestens bis tief in die Semesterferien dauern.
