Ich habe mich gefragt, ob es bei einer besonders großen Datei, beispielsweise 64 MB, möglich ist, den physischen Speicherort der Datei auf der Festplatte herauszufinden und dann Bytes ab einem bestimmten Offset in die Datei einzulesen.
Angenommen, ich interessiere mich für 100 Bytes mit einem Offset von 60 MB vom Anfang der Datei. Ich möchte nicht die Ineffizienzen der Hunderten von Festplattensuchvorgängen in Kauf nehmen, die erforderlich wären, um vom Anfang der Datei zum Ende der Datei zu gelangen, wenn ich eine seek()-Funktion auf Anwendungsebene verwenden würde.
Gibt es eine Lösung?
Vielen Dank!
Antwort1
Sie scheinen eine falsche Vorstellung davon zu haben, wie seek()sich das verhält. Es findet den Ort, an dem die Daten an diesem Offset gespeichert sind, so effizient wie möglich, ohne die dazwischenliegenden Bytes zu lesen. Es werden einige Suchvorgänge (wahrscheinlich nicht Hunderte) erforderlich sein, um den Blockindex zu durchlaufen.
Was Sie nicht tun können, ist, die Durchquerung des Blockindexes von einem Zeitpunkt, an dem die Datei geöffnet wird, bis zum nächsten zu speichern. Das Betriebssystem müsste sich merken, dass die Datei seit dem letzten Öffnen nicht geändert oder verschoben wurde, was das Speichern einer großen Menge an Daten bei einem sehr geringen potenziellen Gewinn erfordern würde.
Beachten Sie, dass sich der Inhalt einer Datei im Allgemeinen nicht an aufeinanderfolgenden Positionen auf der Festplatte befindet. Dateien neigen dazu, fragmentiert zu sein. Dateisysteme versuchen normalerweise, die Fragmentierung zu reduzieren, dies kann jedoch im Allgemeinen nicht garantiert werden.
Antwort2
Beim erneuten Lesen scheint es, als hätte ich die zugrunde liegende Frage möglicherweise nicht beantwortet:
Die Verwendung von „seek“ auf Anwendungsebene (genauer gesagt Kernelebene) führt nicht unbedingt zu Suchvorgängen auf der Festplatte – es wird lediglich die mit dem Datei-Handle verknüpfte Offsetnummer aktualisiert.
Wenn Sie den Kernel zum Lesen oder Schreiben auffordern, konvertiert er diesen Offset in einen Festplatten-Offset. Um dies herauszufinden, müssen möglicherweise Blöcke gelesen werden. Im besten Fall dauert der Vorgang jedoch nur einen Suchvorgang – genau wie bei Ihrem Direktzugriff.
Das ist absolut möglich: Der Dateisystemtreiber macht genau das, also muss es auch für jemand anderen möglich sein. Sie benötigen lediglich Zugriff auf die Rohfestplatte.
Dort Sind von Beispielevon Leuten, die das für bestehende Dateisystemformate tun. Sie können das auch manuell tun, wenn Sie möchten.
Wenn das Dateisystem aktiv verwendet wird, stehen Ihnen einige technische Herausforderungen bevor, die dies erschweren – denn der Inhalt der Festplatte ändert sich auf eine Weise, die Sie nicht direkt erkennen können – aber es ist immer noch möglich.
Sie können den Kernel auch direkt fragen.xfs_bmapDas Tool macht das und zumindest einige Dateisysteme implementieren dieselbe Schnittstelle, sodass Sie direkt fragen können.
Die Berechnung des Speicherorts wird jedoch die gleiche Anzahl von Suchvorgängen erfordern, die der Kernel durchführen würde, so dass Sie wahrscheinlich nicht wirklich sparen werdenirgendetwasDies tun.
Antwort3
Ich glaube nicht.
Öffnet man die Datei, steht man entweder am Anfang (beim Lesen/Schreiben) oder am Ende (beim Anhängen). Auch im "Update-Modus" landet man nicht einfach an einer bestimmten Stelle in der Mitte der Datei.
Ich denke, das Beste, was Sie tun können, ist das, was Sie bereits angedeutet haben: Wenn Sie den Offset von Anfang an berechnen können, könnten Sie direkt zu diesem Speicherort suchen und die Daten lesen. Ich glaube nicht, dass dies zwischendurch übermäßige Lesevorgänge erfordern würde. Ihr nächster Lesevorgang nach dem Öffnen der Datei sollte am berechneten Offset erfolgen.