Принцип разделения памяти:
Добрый день!
Объём eMMC и RAM зависит от исполнения: до 4 ГБ LPDDR4 RAM и до 64 ГБ eMMC. Rootfs на WB8 фиксирована на 2 ГБ вне зависимости от объёма eMMC — вся дополнительная ёмкость уходит в /mnt/data. Именно поэтому устанавливать тяжёлые пакеты в rootfs через apt опасно даже на топовом исполнении с 64 ГБ: лимит rootfs не меняется.
| Раздел | Размер | Точка монтирования |
|---|---|---|
| p1 | ~16 МБ | u-boot (загрузчик) |
| p2 | 2 ГБ | / (rootfs) |
| p5 | ~256 МБ | swap |
| p6 | ~11 ГБ / ~59 ГБ | /mnt/data (16 ГБ / 64 ГБ eMMC) |
Пользователю важно знать два раздела: / (rootfs) — корневой раздел с файлами операционной системы, ссылками на системные настройки, установленным сторонним ПО и его файлами конфигурации; /mnt/data — большой раздел с системными настройками и любыми пользовательскими файлами.
На разделе /mnt/data хранятся логи, база данных MQTT, кеш apt и директория загрузок веб-сервера.
apt install ставит всё в / (rootfs)Стандартный Debian ничего не знает про /mnt/data — это специфика WB. Пакетный менеджер распаковывает файлы по стандартным путям: /usr/bin/, /etc/, /var/lib/ — всё в rootfs. Это штатное поведение Linux, не особенность контроллера.
Для Grafana (~200 МБ бинарников + зависимости) или SCADA это критично: apt install grafana сразу съест значительную часть 2 ГБ rootfs.
Рекомендованный путь — Docker с хранением в /mnt/data.
Docker настраивается через wb-docker-manager.sh так, чтобы образы и volumes хранились в /mnt/data/, а не в rootfs. Типичный стек для Grafana на WB8:
Датчики → MQTT → wb-rules/telegraf → InfluxDB (volume в /mnt/data) → Grafana
Реальный пример: после установки Docker и Home Assistant данные контейнеров (/mnt/data/var/lib/containerd) заняли более 2 ГБ, а вся папка /mnt/data — 6.9 ГБ. При этом rootfs оставалась свободной на 60%.
Правило: всё тяжёлое (Grafana, InfluxDB, Node-RED, SCADA) — только через Docker с хранением в /mnt/data. Прямой apt install допустим только для небольших пакетов из wirenboard-репозитория.
Это встроенная история значений всех MQTT-контролов (показания датчиков, состояния реле и т.д.). Физически данные лежат в /mnt/data/var/lib/wirenboard/ — в разделе данных, не в rootfs. На реальном устройстве wb-mqtt-db занимает около 14 МБ — размер невелик, поскольку встроена автоматическая ротация старых записей. Веб-интерфейс контроллера строит графики именно из этой БД.
Собственная БД для Grafana — это отдельный InfluxDB в Docker, который пишет данные независимо и без ограничений по сроку хранения. Его volume физически находится в /mnt/data/ и rootfs не затрагивает.
Нет — размер раздела rootfs (2 ГБ) задан при сборке прошивки и не меняется в рабочем режиме.
Несмотря на большой eMMC, rootfs по-прежнему 2 ГБ. Переполнить её вполне реально.
Типичные причины:
apt install тяжёлых пакетов напрямую (Node.js, Python-окружения, Grafana)
Docker, установленный не через wb-docker-manager.sh — тогда /var/lib/docker растёт в rootfs
Накопленный системный журнал в /var/log/journal
Кеш apt в /var/cache/apt/archives/
Последствия при заполнении > 95%:
apt перестаёт работать — не может распаковать пакеты во временную директорию
Сервисы падают без возможности записать лог диагностики
wb-rules может зависать или не стартовать
Веб-интерфейс может стать недоступен
/ (rootfs, 2 ГБ — не трогать для тяжёлых программ)
├── ОС Debian, бинарники /usr, /lib
├── /etc → симлинки на /mnt/data/etc
└── Маленькие apt-пакеты (mosquitto-clients, jq и т.п.)
/mnt/data (~11 ГБ на 16 ГБ eMMC / ~59 ГБ на 64 ГБ eMMC)
├── etc/ ← реальные конфиги (сеть, авторизация, правила)
├── var/lib/wirenboard/ ← история MQTT-контролов (wb-mqtt-db, ~14 МБ)
├── var/log/ ← системные логи
├── var/lib/containerd/ ← данные контейнеров Docker (могут занять >2 ГБ)
├── .docker/ ← образы Docker
├── .docker-compose/grafana/ ← Grafana + compose
├── .docker-compose/influxdb/ ← БД для долгосрочного хранения
└── .docker-compose/homeassistant/
Grafana не ставится на контроллер, кстати…
В примере используется отдельный сервер.
А runtime от scada - редко имеют более 50МБ размер.
Коллеги, добрый день.
Остались ли еще вопросы?
Скажите, существуют рекомендации как снизить риск насильственной смерти eMMC от бесконечной одновременной записи в свою базу данных, в базу Home Assistant (или InfluxDB с настройками по умолчанию)?
Добрый день.
Самое радикальное и надёжное решение — перенести всё, что активно пишется, на USB-накопитель или SD-карту (которую дешевле менять):
Смонтировать /var/lib/influxdb, /home/homeassistant/.homeassistant/home-assistant_v2.db и /tmp на отдельный раздел внешнего диска
Или использовать RAM-диск (tmpfs) для временных данных и писать на внешний накопитель только финальные данные
В /etc/influxdb/influxdb.conf или через переменные окружения:
toml
[data]
# Увеличить интервал сброса WAL на диск (default: 10m)
wal-fsync-delay = "100ms"
# Увеличить размер кэша в памяти перед сбросом
cache-max-memory-size = "1g"
cache-snapshot-memory-size = "25m"
# Реже делать compaction
compact-full-write-cold-duration = "4h"
Для InfluxDB 2.x — через influxd.conf:
yaml
storage-wal-fsync-delay: 100ms
storage-cache-max-memory-size: 1073741824
В configuration.yaml:
yaml
recorder:
purge_keep_days: 5 # Хранить меньше истории
commit_interval: 30 # Записывать на диск раз в 30 сек (default: 1)
exclude:
domains:
- media_player
- weather
entity_globs:
- sensor.*_signal_strength
- sensor.*_rssi
commit_interval: 30 — самый простой способ снизить нагрузку на eMMC в разы.
SQLite по умолчанию не очень дружелюбен к flash. PostgreSQL позволяет тонко настраивать fsync, synchronous_commit и checkpoint_completion_target.
noatime, commit для журналаВ /etc/fstab для раздела с данными:
/dev/mmcblk0p2 / ext4 defaults,noatime,commit=60 0 1
noatime — не обновлять время доступа при каждом чтении (убирает огромное количество лишних записей)
commit=60 — сбрасывать журнал раз в 60 секунд вместо 5
Спасибо за развёрнутый ответ. Если всё же есть необходимость в базе с записью чаще обычного и хранением больше обычного, что посоветуете - “правильную” карту в sd-слот или hdd (может с внешним питанием) в usb? Передача на другой хост не подходит - задача обойтись возможностями контроллера.
Контрольный вопрос - у нас же только эти интерфейсы для передачи данных на внешний носитель (в смысле на плате и в смысле чип больше ни чего не поддерживает)?
На плате есть ровно два пути:
USB 2.0 (A/F) — один порт, работает в режиме USB Host.
MicroSD — высокоскоростной слот, до 60 МБ/с на WB8. После установки карта автоматически монтируется в /mnt/sdcard.
Рекомендация: MicroSD, но правильная карта.
Аргументы за MicroSD:
Подключена напрямую к SoC через SDIO, без USB-стека — меньше задержек и накладных расходов
До 60 МБ/с — достаточно для любой БД
Механически надёжнее: нет болтающегося USB-разъёма, нет внешнего блока питания
Карта дешевле заменяется при износе
Аргументы за USB HDD/SSD:
HDD почти не изнашивается от записи (механика, а не flash)
USB SSD с хорошим контроллером (например, Samsung T7) имеет TBW на порядки больше любой SD-карты
Но: нужно внешнее питание (USB 2.0 даёт только 500 мА — для HDD может не хватить), плюс вибрация для HDD, если она существует в месте применения — риск
Какую SD-карту брать:
Обычные карты класса A1/A2 (Sandisk, Samsung) для интенсивной СУБД — плохой выбор, они рассчитаны на последовательную запись (фото/видео). Нужна карта с акцентом на случайную запись и большим ресурсом:
Samsung PRO Endurance — специально для непрерывной записи (видеонаблюдение, логи), ресурс до 43 000 часов записи
Sandisk MAX Endurance — аналогично, 100 000 часов
Любая промышленная MLC/SLC карта (Swissbit, Innodisk, ATP) — если бюджет позволяет, это самый правильный вариант для 24/7
Чего избегать: Sandisk Ultra, Samsung EVO Select и прочие “бытовые” карты — они умирают от случайной записи за месяцы.
Итог: для вашей задачи — MicroSD класса Endurance или промышленная, с монтированием /var/lib/influxdb (или папки HA) туда. Это и дешевле, и проще, и надёжнее в условиях DIN-рейки, чем незафиксированный USB HDD.
Ии может ошибаться) А инженер (по мнению клиента) нет. Статистика, тесты может есть какие?
Ну, как сказать. Специально мы разные тесты не проводили, вот карту которую продавали у себя - за все время меняли пару раз; вполне надежная.
Ну и я предпочитаю вместо карт обычный (хотел написать “советский”) дешевый-медленный SSD через USB адаптер.
Да, громоздко, но опасений что можно “случайно свернуть разъем” в закрытом щите - нет. Ну и вполне вменяемая диагностика состояния.
Вы имеете в виду статистику компании по применению сторонних карт памяти для нагруженных применений? Насколько мне известно,мы такую не собирали )
Мы ответили на ваши вопросы?
да, спасибо, всё ясно - оптимизируем запись, нагруженные БД выносим на внешние диски (eMMC с переходником в sd-слот как до rpi5 делали или ssd to usb)