Запись логов и history на внешнюю USB флэшку

Добрый день.
Воткнул в контролер (WB-6.5) внешнюю USB флэшку.
Скорость чтения и записи, вроде, приличная (до 20Мбайт/с)
Хочу организовать на нее запись всех логов (/var/log/)
и запись history (/mnt/data/var/lib/wirenboard/db/data.db)
Цель:

  • уменьшить изнашиваемость внутренней еMMC памяти
  • Увеличить время/объем хранящихся логов и history.
  • Уменьшить интервалы записываемых данных в history

Вот только не могу сообразить - как это лучше сделать
Не нашел как эти разделы (/var/log/ и /mnt/data/var/lib/wirenboard/db/) ссылаются на /mnt/data
Где и как лучше сделать “переадресацию”?

1 Симпатия

vugluskr, добрый день!
Это директории, вы можете либо сделать на флешке нужные разделы sda1 и sda2, например, и монтировать их поверх этих директорий.
Либо создать аналогичные папки на флешке, а на контроллере заменить их симлинками.
Возможно, вам придется как-то убеждаться, что флешка смонтирована и перезапускать сервисы, которые пишут в лог и базу.

Символьные ссылки пробовал - они не работают:

  • после перезагрузки системы симлинки вроде как присутствуют. Но если посмотреть файл messages по новому пути - он не обновляется.
    Подозреваю, что в этом виновата функция wb_move в скрипте /etc/wb-configs.d/01wb-configs она создает новые ссылки, затирая созданные мной.

А вот монтирование разделов - работает:

  • В файле /etc/fstab добавил пару строк
    /dev/sda1 /mnt/data/var/log auto nofail,noatime 0 2
    /dev/sda2 /mnt/data/var/lib/wirenboard/db auto nofail,noatime 0 2
  • скопировал в созданные разделы старые файлы
  • перезагрузил
    Судя по появлению а в указанных директориях папки /lost+found - все получилось

Но вот смущает меня вывод команды mount:

mount

/dev/mmcblk0p2 on / type ext4 (rw,noatime,errors=remount-ro,stripe=1024,data=ordered)
devtmpfs on /dev type devtmpfs (rw,relatime,size=246120k,nr_inodes=61530,mode=755)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (rw,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
configfs on /sys/kernel/config type configfs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
/dev/mmcblk0p6 on /mnt/data type ext4 (rw,relatime,data=ordered)
/dev/mmcblk0p6 on /var/log type ext4 (rw,relatime,data=ordered)
/dev/sda2 on /mnt/data/var/lib/wirenboard/db type ext4 (rw,noatime,data=ordered)
/dev/sda1 on /mnt/data/var/log type ext2 (rw,noatime,block_validity,barrier,user_xattr,acl)
/dev/sda1 on /var/log type ext2 (rw,noatime,block_validity,barrier,user_xattr,acl)
tmpfs on /run/user/0 type tmpfs (rw,nosuid,nodev,relatime,size=50964k,mode=700)

Здесь разделы /dev/mmcblk0p6 и /dev/sda1 дублируются.
Подозреваю, что это опять связано с функцией wb_move
Можете это как то прокомментировать - не вызовет ли это каких то последствий?

С history что то пошло не так - старые данные не читаются, файл не обновляется.
Пришлось удалить файл /mnt/data/var/lib/wirenboard/db/data.db
и перезапустить сервис - wb-mqtt-db

Продолжу общение (сам с собой :):
После суток работы на внешней флэшке решил посмотреть статистику загрузки блочных устройств:

~# iostat -d -t
Linux 4.9.22-wb6 (wirenboard-AOWCONDB) 09.10.2019 armv7l (1 CPU)
_
09.10.2019 13:24:45
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
mmcblk0 7,77 2,46 24,86 139721 1410040
mmcblk0boot1 0,00 0,00 0,00 104 0
mmcblk0boot0 0,00 0,00 0,00 104 0
sda 0,77 0,25 6,63 14414 376332

статистика 1

root@wirenboard-AOWCONDB:~# iostat -d -t -p sda
Linux 4.9.22-wb6 (wirenboard-AOWCONDB) 09.10.2019 armv7l (1 CPU)

09.10.2019 13:25:09
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda 0,78 0,25 6,64 14414 377080
sda2 0,66 0,09 6,20 5141 351768
sda1 0,11 0,15 0,45 8741 25312

root@wirenboard-AOWCONDB:~# iostat -d -t -p mmcblk0
Linux 4.9.22-wb6 (wirenboard-AOWCONDB) 09.10.2019 armv7l (1 CPU)

09.10.2019 13:25:31
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
mmcblk0 7,77 2,46 24,86 139721 1411116
mmcblk0p4 0,00 0,00 0,00 5 0
mmcblk0p2 0,17 1,31 1,04 74303 58776
mmcblk0rpmb 0,00 0,00 0,00 0 0
mmcblk0boot0 0,00 0,00 0,00 104 0
mmcblk0p5 0,00 0,02 0,00 1164 0
mmcblk0p3 0,00 0,02 0,00 1032 0
mmcblk0p1 0,00 0,01 0,00 292 0
mmcblk0boot1 0,00 0,00 0,00 104 0
mmcblk0p6 4,06 1,10 23,82 62269 1352332

Видно, что средняя скорость записи на флэшку - 6 кбайт/с , а на MMC - 25 кбайт/c.
Т.е. затея моя оказалась бессмысленной?
Стал смотреть статистику по частоте обновлений файлов на /mnt/data/. Это оказался файл - /mnt/data/var/lib/wirenboard/wbrules-vcells.db !
Вот он - убийца флэш памяти!! - подумал я и вcю директорию - /mnt/data/var/lib/wirenboard/ перенес на раздел /dev/sda2

После перезагрузки системы подождал полчаса и вновь снял статистику:

iostat -d -t
Linux 4.9.22-wb6 (wirenboard-AOWCONDB) 09.10.2019 armv7l (1 CPU)
_
09.10.2019 14:22:13
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
mmcblk0 2,15 69,56 2,39 108077 3708
mmcblk0boot1 0,02 0,07 0,00 104 0
mmcblk0boot0 0,02 0,07 0,00 104 0
sda 7,24 8,10 50,19 12586 77984

статистика 2

root@wirenboard-AOWCONDB:~# iostat -d -t -p mmcblk0
Linux 4.9.22-wb6 (wirenboard-AOWCONDB) 09.10.2019 armv7l (1 CPU)

09.10.2019 14:25:15
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
mmcblk0 1,96 62,50 2,32 108077 4020
mmcblk0p4 0,00 0,00 0,00 5 0
mmcblk0p2 1,49 41,28 1,39 71383 2412
mmcblk0rpmb 0,00 0,00 0,00 0 0
mmcblk0boot0 0,02 0,06 0,00 104 0
mmcblk0p5 0,01 0,67 0,00 1164 0
mmcblk0p3 0,01 0,60 0,00 1032 0
mmcblk0p1 0,01 0,17 0,00 292 0
mmcblk0boot1 0,02 0,06 0,00 104 0
mmcblk0p6 0,42 19,40 0,93 33545 1600

root@wirenboard-AOWCONDB:~#
root@wirenboard-AOWCONDB:~# iostat -d -t -p sda
Linux 4.9.22-wb6 (wirenboard-AOWCONDB) 09.10.2019 armv7l (1 CPU)

09.10.2019 14:25:19
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda 7,23 7,26 50,35 12586 87244
sda2 7,07 4,21 50,07 7293 86768
sda1 0,15 2,75 0,27 4761 476

Как видно - теперь все выглядит наоборот.
Жду ваших комментариев.

2 Симпатий

Мне кто нибудь ответит - почему wb-rules за 2-е суток записал на флэшке почти 8 Гбайт?
Глобальных переменных в моих скриптах нет.

1 Симпатия

8 Гб за двое суток – это многовато, мягко говоря. Адресую ваш вопрос программистам, возможно, они ответят или предложат способ диагностики.

Есть предварительные результаты? Когда происходит запись в эту БД? Чего избегать в правилах для минимизации записи?

пока нет, задача в работе.

Так же решил вынести логи и данные WB на внешнюю флешку, т.к. за неделю записалось 10Гб.
Но вот не могу понять пока, кто пишет еще на основной диск.
изображение
изображение
Обьем записи на emmc конечно уменьшился, но хотелось бы сделать 0.

Показания, похоже, сняты после перезагрузки системы - такой поток на чтение данных наблюдается только при старте. Через несколько часов работы iostat показывает совсем другую “картину”, где рейтинг чтения с блочного устройства десятые доли kB/S.
iostat постоянно усредняет данные, показывая накопительные усредненные данные.

А вообще, у себя я искал файлы, к которым постоянно идет обращение на запись с помощью утилиты find:

find /mnt -type f -mmin -1
/mnt/data/var/lib/wirenboard/db/data.db
/mnt/data/var/lib/wirenboard/wbrules-vcells.db
/mnt/data/var/log/mosquitto/mosquitto.log
/mnt/data/var/log/messages

Здесь найдены файлы, обращение на запись к которым было 1 минуту назад.

2 Симпатий

Привожу статистику после 20 часов работы
изображение

По поводу файлов, к которым идет обращение на запись:
find / -type f -mmin -1 ! -path “/proc/*”
Такой поиск выдает еще довольно интересные вещи.

/var/log/messages
/var/log/mosquitto/mosquitto.log
/mnt/data/var/lib/wirenboard/wbrules-vcells.db
/mnt/data/var/log/messages
/mnt/data/var/log/mosquitto/mosquitto.log
/sys/kernel/config/device-tree/overlays/wb6-w2:wb6-wx-1wire/status
/sys/kernel/config/device-tree/overlays/wb6-w2:wb6-wx-1wire/path
/sys/kernel/config/device-tree/overlays/wb6-w1:wb6-wx-1wire/status
/sys/kernel/config/device-tree/overlays/wb6-w1:wb6-wx-1wire/path
/sys/kernel/config/device-tree/overlays/wb6-rs485-2:wb6-can-rs485/status
/sys/kernel/config/device-tree/overlays/wb6-rs485-2:wb6-can-rs485/path
/sys/kernel/config/device-tree/overlays/wb6-rs485-1:wb6-can-rs485/status
/sys/kernel/config/device-tree/overlays/wb6-rs485-1:wb6-can-rs485/path
/sys/devices/virtual/net/ppp0/netdev_group
/sys/devices/virtual/net/ppp0/addr_len
/sys/devices/virtual/net/ppp0/flags
/sys/devices/virtual/net/ppp0/statistics/rx_nohandler
/sys/devices/virtual/net/ppp0/statistics/tx_fifo_errors
/sys/devices/virtual/net/ppp0/statistics/rx_frame_errors
/sys/devices/virtual/net/ppp0/statistics/rx_missed_errors
/sys/devices/virtual/net/ppp0/statistics/collisions
/sys/devices/virtual/net/ppp0/statistics/tx_aborted_errors
/sys/devices/virtual/net/ppp0/statistics/tx_dropped
/sys/devices/virtual/net/ppp0/statistics/tx_carrier_errors
/sys/devices/virtual/net/ppp0/statistics/rx_crc_errors
/sys/devices/virtual/net/ppp0/statistics/tx_errors
/sys/devices/virtual/net/ppp0/statistics/tx_packets
/sys/devices/virtual/net/ppp0/statistics/rx_compressed
/sys/devices/virtual/net/ppp0/statistics/rx_fifo_errors
/sys/devices/virtual/net/ppp0/statistics/tx_bytes
/sys/devices/virtual/net/ppp0/statistics/rx_over_errors
/sys/devices/virtual/net/ppp0/statistics/rx_length_errors
/sys/devices/virtual/net/ppp0/statistics/rx_dropped
/sys/devices/virtual/net/ppp0/statistics/rx_errors
/sys/devices/virtual/net/ppp0/statistics/multicast
/sys/devices/virtual/net/ppp0/statistics/tx_window_errors
/sys/devices/virtual/net/ppp0/statistics/rx_packets
/sys/devices/virtual/net/ppp0/statistics/tx_heartbeat_errors
/sys/devices/virtual/net/ppp0/statistics/rx_bytes
/sys/devices/virtual/net/ppp0/statistics/tx_compressed
/sys/devices/virtual/net/ppp0/gro_flush_timeout
/sys/devices/virtual/net/ppp0/mtu
/sys/devices/virtual/net/ppp0/dormant
/sys/devices/virtual/net/ppp0/link_mode
/sys/devices/virtual/net/ppp0/phys_port_id
/sys/devices/virtual/net/ppp0/power/runtime_suspended_time
/sys/devices/virtual/net/ppp0/power/autosuspend_delay_ms
/sys/devices/virtual/net/ppp0/power/runtime_active_time
/sys/devices/virtual/net/ppp0/power/control
/sys/devices/virtual/net/ppp0/power/runtime_status
/sys/devices/virtual/net/ppp0/duplex
/sys/devices/virtual/net/ppp0/dev_port
/sys/devices/virtual/net/ppp0/queues/tx-0/byte_queue_limits/limit_min
/sys/devices/virtual/net/ppp0/queues/tx-0/byte_queue_limits/inflight
/sys/devices/virtual/net/ppp0/queues/tx-0/byte_queue_limits/limit
/sys/devices/virtual/net/ppp0/queues/tx-0/byte_queue_limits/limit_max
/sys/devices/virtual/net/ppp0/queues/tx-0/byte_queue_limits/hold_time
/sys/devices/virtual/net/ppp0/queues/tx-0/tx_timeout
/sys/devices/virtual/net/ppp0/queues/tx-0/xps_cpus
/sys/devices/virtual/net/ppp0/queues/tx-0/tx_maxrate
/sys/devices/virtual/net/ppp0/queues/rx-0/rps_cpus
/sys/devices/virtual/net/ppp0/queues/rx-0/rps_flow_cnt
/sys/devices/virtual/net/ppp0/phys_switch_id
/sys/devices/virtual/net/ppp0/proto_down
/sys/devices/virtual/net/ppp0/operstate
/sys/devices/virtual/net/ppp0/broadcast
/sys/devices/virtual/net/ppp0/speed
/sys/devices/virtual/net/ppp0/addr_assign_type
/sys/devices/virtual/net/ppp0/tx_queue_len
/sys/devices/virtual/net/ppp0/carrier_changes
/sys/devices/virtual/net/ppp0/ifalias
/sys/devices/virtual/net/ppp0/iflink
/sys/devices/virtual/net/ppp0/phys_port_name
/sys/devices/virtual/net/ppp0/dev_id
/sys/devices/virtual/net/ppp0/ifindex
/sys/devices/virtual/net/ppp0/carrier
/sys/fs/cgroup/systemd/user.slice/user-0.slice/cgroup.clone_children
/sys/fs/cgroup/systemd/user.slice/user-0.slice/session-c6.scope/cgroup.clone_children
/sys/fs/cgroup/systemd/user.slice/user-0.slice/session-c6.scope/tasks
/sys/fs/cgroup/systemd/user.slice/user-0.slice/session-c6.scope/notify_on_release
/sys/fs/cgroup/systemd/user.slice/user-0.slice/user@0.service/cgroup.clone_children
/sys/fs/cgroup/systemd/user.slice/user-0.slice/user@0.service/notify_on_release
/sys/fs/cgroup/systemd/user.slice/user-0.slice/user@0.service/init.scope/cgroup.clone_children
/sys/fs/cgroup/systemd/user.slice/user-0.slice/user@0.service/init.scope/tasks
/sys/fs/cgroup/systemd/user.slice/user-0.slice/user@0.service/init.scope/notify_on_release
/sys/fs/cgroup/systemd/user.slice/user-0.slice/tasks
/sys/fs/cgroup/systemd/user.slice/user-0.slice/session-c7.scope/cgroup.clone_children
/sys/fs/cgroup/systemd/user.slice/user-0.slice/session-c7.scope/tasks
/sys/fs/cgroup/systemd/user.slice/user-0.slice/session-c7.scope/notify_on_release
/sys/fs/cgroup/systemd/user.slice/user-0.slice/notify_on_release
/sys/fs/cgroup/systemd/user.slice/user-0.slice/cgroup.procs
/sys/fs/cgroup/systemd/system.slice/nodered.service/cgroup.clone_children
/sys/fs/cgroup/systemd/system.slice/nodered.service/tasks
/sys/fs/cgroup/systemd/system.slice/nodered.service/notify_on_release
/run/wb-dw-confed-reply

Что-то много дополнительных файлов получилось.

/sys и /run это системные виртуальные разделы tmpfs, которые монтируются в ОЗУ.

Посмотрите, что у вас появляется в

и

В mosquitto.log лежат сообщения о подключении из NodeRed для получения данных.
В messages падали сообщения об ошибках подключения к счетчику электроэнергии и задании в нем параметров(временно отключен).
Соответственно надо поднастроить mosquito. Счетик из списка rs485 и ошибки не падают больше.