[Python-de] Daten in Datei einfuegen

Georg Mischler schorsch at schorsch.com
Don Apr 22 14:32:57 CEST 2004


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/