Сохранение старых блоков на внешнем жестком диске и последних блоков на SSD

Я хотел бы сохранить последние 512 МБ блоков на моем SSD (используя обрезку?), а остальную часть блокчейна на внешнем жестком диске, отличном от SSD. Есть ли способ сделать это уже, или мне нужно написать сценарий для этого?

Вы используете Bitcoin Core или какой-либо другой клиент? Пожалуйста, добавьте соответствующий тег.
Обратите внимание, что вы можете добиться аналогичного прироста производительности, поместив все блоки на внешний жесткий диск (например, создав .bitcoin/blocksсимволическую ссылку) и оставив состояние цепи и другие базы данных с интенсивным доступом на SSD.
@NateEldredge Да, Ядро. Я добавил этот тег.
@NateEldredge Да, с точки зрения производительности это было бы хорошо, но я не хочу, чтобы внешний жесткий диск работал постоянно, как это должно быть, если бы на нем хранились последние блоки. (Я на ноутбуке, поэтому есть ограничения по энергии.)
Я понимаю. Но я не удивлюсь, если вы получите довольно частые запросы на старые блоки от узлов, пытающихся синхронизироваться в первый раз. Bitcoin Core попытается удовлетворить эти запросы и раскрутить внешний диск. Таким образом, в зависимости от ваших настроек тайм-аута, я ожидаю, что вы либо будете использовать этот диск большую часть времени, либо много крутить его вверх и вниз (что не очень хорошо для его срока службы).
@NateEldredge Да, это то, о чем я задавался вопросом: какой процент узлов в среднем все равно будет запрашивать старые блоки.
я думаю, вы можете удалить флаг службы обслуживания блоков, чтобы сверстники не запрашивали у вас исторические блоки.
Или просто установите maxuploadtarget очень низким.
Интересно, сработает ли запуск двух экземпляров bitcoind, один с полными блоками, другой с сокращенным, и позволит экземпляру с полным блоком обслуживать только сокращенный экземпляр.

Ответы (4)

Доступ к блокам в обычном режиме невозможен, за исключением следующих случаев: Когда одноранговый узел извлекает один блок (а самый последний блок обычно обслуживается из кэша в памяти), когда происходит реорганизация, которая должна отменить действие блока (что бывает довольно редко). ) или когда вы используете RPC для поиска исторического блока.

Имея это в виду, возможно, вы можете просто поместить каталог блоков на другой диск.

Если вы настроите свой узел на отсечение, но установите количество отсечения намного больше, чем объем данных блока, вы избежите получения пирами большого количества старых блоков от вас (но все равно сохраните данные).

Если вы обнаружили высокий доступ к диску в этой конфигурации, я думаю, что это то, что проект хотел бы исправить.

У вас может быть два каталога данных, один локальный и один на внешнем жестком диске, куда время от времени вы подключаете внешний жесткий диск и запускаете Bitcoin Core, чтобы использовать его в качестве каталога данных и синхронизировать его. Местный можно обрезать.

Однако, если вы хотите, чтобы большинство блоков хранилось на внешнем жестком диске, и чтобы Bitcoin Core автоматически перемещал их туда, а затем имел возможность обрабатывать, когда он не может найти эти блоки, то это невозможно.

Если вы уже синхронизированы, вы можете вызвать простой скрипт, используя blocknotify=script.shсвой bitcoin.conf, чтобы проверить наличие файла блока с более высоким номером, и, если он найден, переместить самый низкий файл и самый новый.

Но лучшим способом, вероятно, было бы сделать это на уровне блоков с некоторой абстракцией fs/raid или наблюдателем inotify, если вам нужно сделать это на уровне файлов.

Я не думаю, что это сработает, так как впоследствии биткойн может попытаться получить доступ к файлу. Даже если вы замените его символической ссылкой, к нему можно получить доступ между удалением старого файла и созданием ссылки.
Да, наверное, ты прав. Я бы просто провел рейд на ssd и hdd вместе, но если это невозможно и вам нужно сделать это, перемещая файлы blk.dat, вероятно, самым безопасным вариантом будет (1) просмотр blocksкаталога на наличие новых файлов с помощью inotify; (2) остановить службу bitcoind, (3) переместить самый новый файл на ssd, (4) переместить самый старый файл с ssd на жесткий диск, (5) повторно связать эти два файла с blocks, (6) перезапустить bitcoind.

https://statoshi.info/dashboard/db/unspent-transaction-output-set

серийный набор UXTO составляет 4 ГБ по состоянию на апрель 2020 года.

Вы можете положить все в оперативную память и жесткий диск. SSD имеет ограниченный срок службы, особенно если у вас слишком много операций записи.