DAG-Größe (Win 10) erheblich größer als erwartet

Letzte Nacht habe ich auf eine viel neuere Version der Mist Ethereum-Brieftasche aktualisiert als vor ungefähr einem Jahr, als ich sie zuletzt verwendet habe (0.2.6 bis 0.8.9), und nach allem, was ich über die DAG-Größe gelesen habe, verwendet sie weitaus mehr Speicherplatz, als er sein sollte (weshalb ich es zuvor nie von meiner SSD ausführen konnte - es würde mehr als 10 GB verbrauchen und der 90%-Marke meines mickrigen 128-GB-Startlaufwerks zu nahe kommen, und ich müsste abbrechen es).
Letzte Nacht habe ich endlich 'mklink' herausgefunden, und der DAG synchronisiert glücklich, weil er denkt, er sei in %appdata%, obwohl er tatsächlich auf eine Stelle auf meinem sich drehenden Festplattenlaufwerk zeigt.

Die Wallet-App scheint damit in Ordnung zu sein. Es erkannte genau, wo ich war, als ich das letzte Mal den DAG synchronisiert hatte, und ging von dort aus weiter (ich hatte vor 4 Stunden knapp 1 Million Blöcke vor mir). Ich habe mir notiert, wie viel freier Speicherplatz ich hatte, als ich mit dem Synchronisierungsvorgang begann, damit ich wusste, wie viel er einnahm.

Schneller Vorlauf bis jetzt: Als ich es aufschrieb, hatte ich 360 GB frei auf der Festplatte, die ich verwende. Ab sofort (75,7 % Synchronisierung) habe ich nur noch 337 GB frei oder etwa 23 GB DAG. Dementsprechend ist der Ordner „chaindata“, mit dem es synchronisiert wird, zum Zeitpunkt des Schreibens genau 30 GB groß (7 GB wurden vor 1 Jahr oder länger heruntergeladen).

Dies ist das gleiche Verhalten, das ich gesehen habe, bevor ich den DAG mit mklink verschoben habe, also glaube ich nicht, dass das etwas damit zu tun hat - tatsächlich hatte ich noch nie einen vollständig synchronisierten DAG auf meinem PC (nur mein Mining rig, vor über einem Jahr, als es viel kleiner war), weil es niemals auf meinen dürftigen verbleibenden SSD-Platz passen würde.

Wenn es diagnostisch hilft, enthält das 'chaindata'-Verzeichnis 16.060 Elemente (Tendenz steigend), jedes ca. 2 MB und beginnend chronologisch mit 047061.LDB (im Jahr 2016) bis zur Gegenwart 191120.LDB (wird schnell von neueren Dateien an sich gerissen).

Irgendwelche Ideen?

Vielen Dank,

-Aaron

Bearbeiten: Synchronisierung jetzt zu 86 % abgeschlossen, /chaindata bis zu 36 GB

Edit2: Synchronisierung jetzt zu 98 % abgeschlossen, /chaindata bis zu 43 GB

Antworten (2)

Ich denke, Sie verwechseln den DAG möglicherweise mit den anderen Kettendaten. Der DAG wird nur für das Mining verwendet und nimmt nur etwa 2 GB ein. Was den Platz einnimmt, ist die gesamte Blockchain, die Sie gerade herunterladen (das ist „synchronisieren“. 40 GB sind ungefähr richtig, und bis Light Clients verfügbar werden, müssen Sie sich damit befassen. Die Kettendaten Der Ordner wächst langsamer weiter, auch wenn Sie mit der Synchronisierung fertig sind.

Ja, ich habe die beiden tatsächlich verwechselt - hauptsächlich, weil bei Verwendung der Befehlszeile: geth.exe --datadir [gewünschter Speicherort] der Initialisierungstext für geth "Datenspeicherort: [neuer gewünschter Speicherort]" lautete. DAG-Speicherort: [alter %appdata% location], und das Laufwerk c:\ wuchs weiter mit der gleichen Rate (was es schon lange vor Abschluss der Synchronisierung der Kette gefüllt hätte). kann die /chaindata/ auf einem Laufwerk mit viel Speicherplatz aufbewahren, aber ich hatte immer noch den irrtümlichen Eindruck, dass DAG gleichbedeutend mit den Chaindata ist. Danke!

Ich bin eigentlich neu hier und hätte ein paar Fragen. 100 GB scheinen nicht genug zu sein, um diese Art von Operation durchzuführen. Gibt es eine Möglichkeit, diesen Prozess zu verschlanken und zu optimieren?

Ich würde lieber nur 2-5 GB verwenden und trotzdem minen können.

Bitte durchsuchen Sie die Website und stellen Sie eine neue Frage , wenn Sie nicht finden, wonach Sie suchen .