Dateizugriff. Daten non-sequentiell lesen/schreiben
-
Beim seeken wird die Datei nicht unbedingt eingelesen AFAIK.
-
Hängt das nicht auch stark davon ab, welche API oder Library du verwendest?
-
Kommt drauf an,
ist es eine kleine Datei, dann steht diese Datei mit großer Wahrscheinlichkeit beim ersten Zugriff in irgendeinem Cache(Festplatte/Arbeitsspeicher).
Ist sie sehr groß, dann muss sie eh von vorne bis zum seek eingelesen werden, da eine Datei in Blöcken eingeteilt ist und diese nicht hintereinander stehen, sondern (je nach Dateisystem) z.B. bei FAT irgendwo auf der Festplatte verteilt sind und in eine Art verkettete Liste darstellt. Die einzelnen Blöcke zeigen also auf ihre Nachfolger. Somit müßten die einzelnen Blöcke der Datei bis zu der Stelle durchsucht werden.Du wirst also nicht darum herumkommen die Datei sequentiell einzulesen.
-
@Ingo
das kommt aber ganz auf die Ebene an, in der wir arbeiten. Wenn wir ein normales Anwendungsprogramm schreiben, benutzen wir ja zum Dateinlesen Librarys, zum Beispiel die Standard C++ Library. Wenn wir einfach seek anwenden, dann müssen sich andere Code-Teile um das Problem kümmern, ob die Datei nun sequentiel gelesen wird oder nicht. Für uns sieht das aber eher nach punktuellem lesen aus, auch wenn die Datei vielleicht komplett in den Speicher gemapped wird oder eben auf Filesystem ebene geseeked wird.
-
@kingruedi
Jupp stimmt und nichts anderes habe ich behauptet.
Es ist ziemlich egal, in welcher Ebene du arbeitest, durchgeführt werden muss es ja nun mal, ob nun vom Entwickler selber, oder von den Programmbibliotheken, oder gar vom Betriebssystem.Jedenfalls wird beim seeken die Datei von vorne bis zu diesem entsprechendem Punkt gelesen (abhängig vom Dateisystem), nur brauchen sich die Programmierer, wie du schon richtig gesagt hast, nicht darum kümmern.
-
schonmal was von ISAM gehört?
Hab da mal vor Jahren ne Klasse zu geschrieben...
-
Was soll das sein?
isamclass.exe stürzt ab beim Starten.
-
-
So einen Blödsinn hab ich ja schon lang nicht mehr gelesen. Ein seek führt wahrscheinlich nichtmal auf einem Bandlaufwerk zum kompletten Einlesen bis an diese Stelle.
Ingo aka Desert Hawk schrieb:
Jedenfalls wird beim seeken die Datei von vorne bis zu diesem entsprechendem Punkt gelesen (abhängig vom Dateisystem)
Nehmen wir mal eins der einfachsten Dateisysteme, was jemals professionell eingesetzt wurde ... FAT, AFAIK 1976 von Bill Gates erfunden. Die verkettete Liste, von der du sprichst, ist die File Allocation Table (FAT), die sich in einigen Sektoren am Anfang der Partition befindet. Die ist es, die bei jedem Zugriff durchlaufen muss (ausgeklügelte Caching-Strategien nicht mitgerechnet). Auf die eigentliche Datei wird erst zugegriffen, wenn der Cluster bestimmt wurde, indem die seek-Zielposition liegt.
Da die FAT sich normalerweise hoffentlich im RAM befindet, dauert das auch nicht so lange.Andere Dateisystem sind deutlich ausgeklügelter, es ist ausgeschlossen, dass es ein ernsthaftes Dateisystem für Platten gibt, was seeken durch einlesen realisiert.
-
Du möchtest mir also erzählen, dass in der FAT jeder beschrieben Block einer Festplatte definiert ist?
Also das in der FAT enthalten ist:Datei xxx virtueller Adressraum | zu finden in Block 0-512 5320 512-1024 8120 ... ... ...-4GB 28337Dann überlege mal, wie groß die FAT-Datei sein müßte, damit diese sämtliche Information darin enthalten sein kann. Nun stell dir das gleiche mal vor mit einem Rechner, der 4 Festplatten hat, je Festplatte 40GB, eine Partition 20 GB gross. Also 160GB in 8 Partitionen/FATs aufgeteilt.
Und die gesamte Information möchtest du dann im Arbeitsspeicher halten?Mal davon abgesehen, dass du dann ja abhängig von der maximalen Größe deiner Partition dementsprechend viel Speicherplatz frei in deinen ersten Sektoren freihalten musst, da die FAT ja ständig wächst und schrumpft.
Und wie machen diese tollen Partitionierungsprogramme das denn, dass man eine Partition verkleinern und wieder vergrößern kann, ohne den Inhalt darauf zu löschen (vorrausgesetzt man hat vorher defragmentiert)?So weit ich das gelernt habe, steht in der FAT lediglich drin, welche Datei wo anfängt. Alles weitere wird dann am Ende eines Blockes beschrieben.
Das ist das Prinzip der Bandlaufwerke.
An jedem Ende eines Blockes stehen Informationen, an welcher Position der nächste Block zu finden ist.
Deswegen werden beim damaligen Scandisk auch Dateien nur teilweise rekonstruiert, wenn ein Block irgendwo mittig der Datei defekt war, da die Information verloren ist, wo sich der Rest der Datei befindet.Und bitte sage mir mal, was an dem Konzept der verketteten Listen Blödsinn ist.?.
Bei ext2-Dateisystemen ist die Dateiverwaltung anders, da werden die Blöcke nicht in verketteten Listen auf die Platte geschrieben, sondern als Baum mit den entsprechenden Knoten (I-Nodes) organisiert.
Dass das ganze dennoch relativ schnell funktioniert, liegt an dem Caching.
-
Ach ja, Bill Gates hat FAT bestimmt auch nicht erfunden, aber das weiss ich nicht.
-
Desweiteren möchte ich noch dazu sagen, dass ich der meinung bin, das so gelernt zu haben.
Ist natürlich auch möglich, dass ich mich da auch total täusche (ist ja auch schon lange her
) und gebraucht habe ich dieses Wissen auch bisher noch nicht wieder.Aber das als Blödsinn hinzustellen, verbitte ich mir. :p
-
Ingo aka Desert Hawk schrieb:
Du möchtest mir also erzählen, dass in der FAT jeder beschrieben Block einer Festplatte definiert ist?
Du willst dich unbedingt mit aller Kraft blamieren, oder?
Also das in der FAT enthalten ist:[snip]
Wie die FAT aufgebaut ist, findet sich an allen möglichen Stellen im Netz. STFW.
Dann überlege mal, wie groß die FAT-Datei sein müßte, damit diese sämtliche Information darin enthalten sein kann.
Beispiel: 20 GB Partition, Clustergröße 4kB, ergibt 5242880 Cluster. Jedem Cluster ist in der FAT (FAT32) ein 32bit-Eintrag zugeordnet, macht 20480 kB für eine FAT. Normalerweise gibt es 2 FATs, macht also etwa 40MB für diese Partition. Tja, das mag sich viel anhören, aber da kommt man leider nicht drumherum. Wo gehobelt wird da fallen Späne (die Annahme, die würde immer komplett im Speicher gehalten, ist dann natürlich falsch. Ich hatte es nicht nachgerechnet.)
Und die gesamte Information möchtest du dann im Arbeitsspeicher halten?
Nein, natürlich nicht. Aber das ist MS' Problem. Die FAT einer Diskette ist nur 9 Sektoren (4,5KB) groß, und wurde vielleicht in späteren DOS-Versionen im Speicher gehalten. FAT skaliert halt nicht besonders gut, es hat auch niemand behauptet, dass FAT zeitgemäß wäre.
Mal davon abgesehen, dass du dann ja abhängig von der maximalen Größe deiner Partition dementsprechend viel Speicherplatz frei in deinen ersten Sektoren freihalten musst, da die FAT ja ständig wächst und schrumpft.
Nein, die Größe der FAT ist konstant. Anzahl der verfügbaren Cluster mal Größe eines Eintrags, auf die nächste Sektor- (nicht Cluster-)Grenze aufgerundet.
So weit ich das gelernt habe, steht in der FAT lediglich drin, welche Datei wo anfängt.
Das steht im Verzeichniseintrag. In der FAT stehen nur die jeweiligen next-Pointer, wenn du so willst. Das Ende wird durch einen Wert > 0xFFF7 (bei FAT16, bei FAT32 wahrscheinlich entsprechend mehr F's) angezeigt. Für "Cluster frei" und "Cluster als beschädigt markiert" gibt es ebenfalls spezielle Codes.
An jedem Ende eines Blockes stehen Informationen, an welcher Position der nächste Block zu finden ist.
Wenn das so wäre, würde ja trotzdem die gleiche Informationsmenge für die Verkettungen verbraucht werden.
So und bevor du jetzt noch ein einziges Wort dagegen sagst, bitte ich dich, die entsprechenden Informationen zu recherchieren. FAT ist gründlichst reverse-engineered, du kannst dazu im Netz haufenweise Material finden, oder wenns sein muss ein altes "PC Intern" vom Flohmarkt holen.
-
[quote="Bashar"]
Du willst dich unbedingt mit aller Kraft blamieren, oder?
[quote]Danke, ebenso :p
Zu dem Rest...
muss ich sagen, dass mir da doch einige Erinnerungen wieder hoch kommen, wenn ich das lese. Da hab ich dann wohl etwas durcheinander gebracht.