Диск загружен при запуске stroj на docker

Это решит проблемы с запредельно медленным перезапуском и копированием на другой диск.

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

Конкретно по теме:

  • перезапускать сервер вообще не нужно, разве что если какой то важный хотфикс вышел, который что-то меняет в пользовательским сценарии, может раз в год. И то, я бы три раза подумал стоит ли его ставить, когда плата за удовольствие — вытеснение всех накопленных кешей и дикие тормоза сервера какое то время после. Не только из-за сторж узла.
  • Копировать на другой диск нужно целиком диск, а не по одному файлу, как раз чтобы размеры и количество файлов не имели никакого эффекта на скорость.

zfs на 1 диск, zfs send&rcv через mbuffer даст максимум, что твой диск\сеть способны выдать.
Плюс на zfs можно повесить ssd кэш диск для метадаты. Который ускорит запуск узла в разы.

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

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

1 Like

Действительно, в этом что-то есть.

Так как проблема в чтении метаданных — то тут деваться некуда, надо каким то образом избежать чтения всего каждый раз заново. Как @serger001 написал вверху — это решается на уровне системы, например постоянный (persistent) кеш вроде как раз то что доктор прописал. Вот статья как его конфигурировать на TrueNAS: Docs Hub | L2ARC

Наверное ничего не мешает реализовать похожее кеширование в самом сторж узле — записать прочитанные метаданные в локальный файл, и периодически обновлять его; а на следующем старте просто прочесть его вместо сканирования диска.

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

Может лучшее решение будет просто банально ограничить iops — чтоб не мешать остальным сервисам — пусть себе сканирует хоть два дня.

Я лично никаких проблем с этим не замечаю — ну хрустит массив дисками — все остальные сервисы (plex, iSCSI, SMB) работают нормально, и у меня даже l2arc нет. Просто 32GB памяти на устройстве.

А для однодисковых узлов — может гибридные HDD помогут?

Делали уже так, хранили в БД sqlite. Но при неправильном завершении (свет мигнул или ещё что-то пошло не так) БД повреждалась и не всегда можно было восстановить, так что отказались от этого решения и метаданные теперь хранятся вместе с данными прямо в файлах.
Сейчас БД используется в качестве кэша, обновляется раз в час по умолчанию (параметр --storage2.cache-sync-interval).

1 Like

А где это отключается? В конфиге нет, в докере попробовал, говорит нет такой команды.

Вообще-то есть

docker exec -it storagenode ./storagenode setup --help | grep scan

      --storage2.piece-scan-on-startup                           if set to true, all pieces disk usage is recalculated
on startup (default true)

Выключить можно в config.yaml, указав

storage2.piece-scan-on-startup: false

и перезапустив узел

docker restart -t 300 storagenode

или опцией --storage2.piece-scan-on-startup=false после имени образа в вашей команде docker run, но нужно будет пересоздать контейнер.