Я использую geth 1.4.18-stable-c72f5459 на Win7.
Я начинаю свои узлы со следующими параметрами:
geth.exe --datadir \work\eth\miner2 --nat none --nodiscover --networkid 1999 --mine --port 30304 --ipcpath miner2.ipc
После синхронизации с другим узлом майнера на той же машине второй майнер дает сбой, когда начинает майнить сам.
Мое лучшее предположение на данный момент заключается в том, что у двух экземпляров есть коллизия в AppData\Roaming\Ethash, где хранится DAG. Я искал возможность передать geth другое местоположение, но похоже, что этот путь жестко запрограммирован.
panic: ethash_full_new IO or memory error
goroutine 387 [running]:
panic(0xbce660, 0xc0431f4b80)
/usr/local/go/src/runtime/panic.go:500 +0x1af
github.com/ethereum/ethash.(*dag).generate.func1()
/go/src/github.com/ethereum/go-ethereum/build/_workspace/src/github.com/ethereum/go-ethereum/Godeps/_workspace/src/github.com/ethereum/ethash/ethash.go:273 +0x695
sync.(*Once).Do(0xc0433b5860, 0xc043433bd0)
/usr/local/go/src/sync/once.go:44 +0xe2
github.com/ethereum/ethash.(*dag).generate(0xc0433b5840)
/go/src/github.com/ethereum/go-ethereum/build/_workspace/src/github.com/ethereum/go-ethereum/Godeps/_workspace/src/github.com/ethereum/ethash/ethash.go:277 +0x53
github.com/ethereum/ethash.(*Full).getDAG(0xc0421de330, 0xa3, 0xc04343fc80)
/go/src/github.com/ethereum/go-ethereum/build/_workspace/src/github.com/ethereum/go-ethereum/Godeps/_workspace/src/github.com/ethereum/ethash/ethash.go:333 +0xa7
github.com/ethereum/ethash.(*Full).Search(0xc0421de330, 0x127d300, 0xc043438900, 0xc04349e240, 0x0, 0x0, 0x0, 0x0, 0x0)
/go/src/github.com/ethereum/go-ethereum/build/_workspace/src/github.com/ethereum/go-ethereum/Godeps/_workspace/src/github.com/ethereum/ethash/ethash.go:338 +0x7b
github.com/ethereum/go-ethereum/miner.(*CpuAgent).mine(0xc0433c3720, 0xc0433ac340, 0xc04349e240)
/go/src/github.com/ethereum/go-ethereum/build/_workspace/src/github.com/ethereum/go-ethereum/miner/agent.go:121 +0x13a
created by github.com/ethereum/go-ethereum/miner.(*CpuAgent).update
/go/src/github.com/ethereum/go-ethereum/build/_workspace/src/github.com/ethereum/go-ethereum/miner/agent.go:90 +0x15a
как вы уже догадались, проблема исходит от DAG.
Я думаю, что экземпляры geth генерируют два DAG одновременно. чтобы вы могли отключить его, запустив geth --autodag=falseилиgeth makedag 0 /ethdata/
У меня была такая же проблема в моей удаленной виртуальной машине Windows Azure.
Я решил это
1) Проверка бита geth (32/64) . У меня была 64-битная система, и я запускал 32-битный geth, поэтому столкнулся с этой проблемой.
2) Проверка размера хранилища . У меня была виртуальная машина Azure, размер внутренней памяти/ОЗУ которой составлял всего 3,5 ГБ, чего недостаточно для создания и хранения DAG.
--autodag=falseне работает, потому что как только майнер запускается, включается автоматическая прегенерация. Это также происходит, если я звоню miner.stopAutoDAG()через консоль.
Проблема, похоже, в том, что второй майнер не может прочитать файл DAG, потому что первый майнер заблокировал его. Через оболочку я попытался вызвать md5sumфайл DAG во время работы первого майнера и получил md5sum: can't open 'full-R23-0000000000000000': Device or resource busy.
Единственное решение, которое пока сработало для меня, — это запустить второй майнер с другой учетной записью Windows.
После запуска 64-битного гета все работает нормально. У меня винда тоже 64 битная.
конфиденциальностьisahumanright.eth
--autodag=falseне работает. Запуститеgethс этим параметром, и вы все равно увидите сообщениеAutomatic pregeneration of ethash DAG ON.