Alexander 'boesi' Bösecke wrote:
Georg Mischler schrieb:
Unter unix kannst du ein seek() über das Dateiende hinausmachen, wodurch automatisch alles bis zu deiner neuen Position mit \0 gefüllt wird. Das Dateisystem alloziert für Blocks (Grösse variiert), in die du nichts geschrieben hast, auch keinen Platz auf der Platte. Erst wenn du dort das erste mal tatsächlich etwas hinschreibst (und seien es lauter explizite \0), wird physikalisch Raum beansprucht.
Meinst du soetwas hier? FileSize = 1048576 f = open('test.txt', 'w') f.seek(FileSize - 1) f.write('.') f.close()
Das erzeugt bei mir (XP, getestet auf FAT32 und NTFS) eine 1MB grosse Datei.
Auch unter unix wird dir "ls" eine 1MB grosse Datei anzeigen. Mit "du" siehst du aber, dass sie physikalisch nur einen einzigen Block belegt (512-4096k, je nach Grösse des Dateisystems). Sobald du um unteren Bereich etwas reinschreibst, wird das Dateisystem die dazu notwendigen Blöcke ebenfalls allozieren. Es is theoretisch möglich, dass moderne Windows Dateisysteme (NTFS) so etwas auch unterstützen, aber ich habe keine Ahnung, wie man dort den Unterschied feststellen könnte.
Unter anderen Systemen, und vielleicht auch bei einigen exotischen Dateisystemen unter unix, funktioniert das meines Wissens so nicht.
Ich kann mich also nicht drauf verlassen, dass die obige Methode auf jedem Dateisystem funktioniert? Oder wovon ist das abhaengig?
Von der Unterstützung des Dateisystems. Das müsstest du ggf. mit jedem in Frage kommenden System ausprobieren.
Muss das wirklich eine einzelne grosse Datei sein? ...
Also die Daten gehoeren schon zu einer Datei.
Warum?
Mit der obigen Methode dauert das erzeugen einer 700MB grossen Datei, 700 1MB oder 70 10MB grossen Dateien PiMalDaumen gleich lang.
Das ist auch genau die Strategie der meisten unix Dateisysteme. Fragmentierung lässt sich nie grundsätzlich verhindern. Aber wenn ich dafür sorge, dass nach Möglichkeit immer mindestens z.B. 1MB am Stück geschrieben/gelesen werden können, dann sind die negativen Effekte vernachlässigbar. Bei fast voller Platte lässt sich natürlich nicht mehr viel machen (wie Daniel schon erwähnt hat).
Von daher waere das egal, aber ich glaub nicht das ich soviele Dateien auf Platte haben will.
Warum nicht? Pack sie halt in ein extra Verzeichnis, dann ist die Liste aus dem Blickfeld. Am Ende sind doch alles nur Sektoren auf der Platte. Du hast zwar geringfügig mehr Arbeit, aber du musst dich zum Platzsparen nicht auf die Hilfe des Dateisystems verlassen, und es ist auch ohne interne Listen gleich offensichtlich, welche Teile der Daten schon existieren.
Aber das bringt mich auf eine Idee: Man koennte die Bloecke in einer "DBM-Datei" speichern, als Index wuerde ein str(BlockPos) dienen. Weiss jemand spontan, wie weit dabei die Geschwindigkeit beim schreiben und lesen einbrechen wuerde?
Das musst du ausprobieren, aber für eine letzten Endes lineare Sequenz von Datenblöcken scheint mir das Overkill zu sein. -schorsch -- Georg Mischler -- simulations developer -- schorsch at schorsch com +schorsch.com+ -- lighting design tools -- http://www.schorsch.com/ _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de