И еще раз про вытирание флешки и как его замедлить

Программное обеспечение
1

Соскучились? Привет.

Я тут сказал одному контроллеру, еще практически голому, mosquitto_sub -v -t /#
И - повалилоооо. На 99% это показания трех АЦП (не указанных, на минуточку, в конфигах), вольтметров Vin и 5Vout. Так как напряжения по-любому мотыляются в пределах десятков милливольт, топики сыплются непрерывно.
Полагаю, сыплются они в том числе в /mnt/data/var/lib/wirenboard/db/data.db, размер которой уже под 20 метров, несмотря на небольшой аптайм машинки.
Прибил сервис wb-homa-adc. Полегчало.

Вот предлагаю делиться советами, как избежать бессмысленного натирания далеко не вечной флешки. Сислоги я лично вынес на общий внешний сервак посредством syslog-ng, теперь вот прибил опрос АЦП. Наверняка есть еще процессы, которые напрасно (в контексте использования, конечно) жуют диск, и которые можно сконфигурить этого не делать.

2

Добрый день!

TL;DR: проблемы не существует, флешка вечная, ничего делать не надо.

Ресурс встроенного носителя можно оценить так: всего на него гарантированно можно записать данных X * 8GByte * 10000, где 8GByte - общая ёмкость накопителя в WB6, 10000 - нижняя граница количества перезаписей ячейки памяти MLC, X - множитель усиления записи, от 0.1 до 1, в зависимости от характера записей.

Итого, речь идёт о числах порядка 20 терабайт, которые гарантированно можно записать. Реальная скорость, с которой идёт запись на флешку свежего контроллера - единицы килобайт в секунду. Можно проверить, запустив iotop с опциями. Так получается, потому что wb-mqtt-db пишет в базу раз в две минуты по-умолчанию, другие сервисы тоже, ещё есть всякие кеши ОС и т…д

Со скоростью 1 KB/s 20 терабайт запишутся через 600 лет.

Исчерпать ресурс флешки конечно можно, но это специально нужно сделать что-то очень-очень странное, например непрерывно писать на неё мегабайты в секунду. Стандартное ПО Wiren Board так не делает по-умолчанию, и даже настроить его как-то, чтобы выйти на такие скорости, вам не удастся. За много лет и много тысяч контроллеров мы не видели ни одного случая исчерпания ресурсов встроенной флешки.

Предполагаю, что ноги у городской легенды про ограниченный ресурс flash растут из опыта работы с консьюмерскими microSD-картами на TLC памяти и с плохими контроллерами. Даже там, скорее всего, большинство реальных выходов из строя карточек - это ошибки или выход из строя встроенного контроллера, а не реальное исчерпание ресурса.

3

Я очень стар. Я суперстар! и начинал с самых первых мегабитных чипов, как только их анонсировал Интел. ОК, “страхи” еще оттуда, из девяностых.
Оттуда же (вернее, из восьмидесятых) неистребимый топор Оккама на тему всего лишнего вообще.
Вот сейчас прибил странный сервис wb-mqtt-knx, вся деятельность которого заключается в непрерывной писанине в /var/log/error, что демон не может запуститься, ибо модуль knx не найден. Понятное дело, я ж его не покупал.
Итд итп.

Засим ворчбу прекращаю, а топик прошу оставить. Для старперов - нелюбителей лишнего.

1 лайк
4

Тут ключевое отличие в том, что eMMC - это не просто флешка, это флешка с контроллером. Контроллер размазывает записи равномерно по чипу, поэтому и ресурс измеряется в байтах, а не в количествах перезаписи. Если работать с флешкой напрямую, никакого выравнивания износа не делать, то тогда каждая перезапись определённой ячейки перезаписывает именно определённую ячейку и её очень просто “протереть”. А в eMMC при перезаписи блока каждый раз запись фактически происходит в новое место, чтобы равномерно использовать ресурс.

1 лайк
5

Можно вынести базу на отдельную USB-флешку - я так сделал, т.к. пишется много чего и хранится долго (сейчас объем больше 1 Гб). Остальное там вообще килобайты (если правильно настроить логи).

6

Вероятно, я кривовато выразился, формулируя первый мессыч.
Retained база нужна - но нужны ли в ней неиспользуемые АЦП каждые несколько десятков мс? Логи нужны, но зачем там ошибки от демона, который не может взлететь по причине отсутствия по дефолту обслуживаемого им железа. Итд.
(За knxd я не уверен, впрочем: на этом контроллере крутится экспериментальный образ из ветки про modbus/tcp)

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

1 лайк
7

После apt-get upgrade началось.
/var/log/messages на 99.6% состоит из нижепроцитированного. Как это убрать? В mosquitto.conf строчка про логи не менялась, причем в свой лог он кладет не так уж много. А вот системный забивается наглухо…

Jun 20 19:17:03 wirenboard-AGPLM2T7 New client connected from 127.0.0.1 as mosqpub|22310-wirenboar (c1, k60).
Jun 20 19:17:03 wirenboard-AGPLM2T7 Client mosqsub|22309-wirenboar disconnected.
Jun 20 19:17:03 wirenboard-AGPLM2T7 Client mosqpub|22310-wirenboar disconnected.
Jun 20 19:17:03 wirenboard-AGPLM2T7 New connection from 127.0.0.1 on port 1883.
Jun 20 19:17:05 wirenboard-AGPLM2T7 New client connected from 127.0.0.1 as mosqsub|22393-wirenboar (c1, k60).
Jun 20 19:17:05 wirenboard-AGPLM2T7 New connection from 127.0.0.1 on port 1883.
Jun 20 19:18:01 wirenboard-AGPLM2T7 New client connected from 127.0.0.1 as mosqpub|22407-wirenboar (c1, k60).
Jun 20 19:18:01 wirenboard-AGPLM2T7 Client mosqsub|22393-wirenboar disconnected.
Jun 20 19:18:01 wirenboard-AGPLM2T7 Client mosqpub|22407-wirenboar disconnected.
Jun 20 19:18:01 wirenboard-AGPLM2T7 New connection from 127.0.0.1 on port 1883.
Jun 20 19:18:04 wirenboard-AGPLM2T7 New client connected from 127.0.0.1 as mosqsub|22484-wirenboar (c1, k60).
Jun 20 19:18:04 wirenboard-AGPLM2T7 New connection from 127.0.0.1 on port 1883.
Jun 20 19:19:02 wirenboard-AGPLM2T7 New client connected from 127.0.0.1 as mosqpub|22485-wirenboar (c1, k60).
Jun 20 19:19:02 wirenboard-AGPLM2T7 Client mosqsub|22484-wirenboar disconnected.
Jun 20 19:19:02 wirenboard-AGPLM2T7 Client mosqpub|22485-wirenboar disconnected.
Jun 20 19:19:02 wirenboard-AGPLM2T7 New connection from 127.0.0.1 on port 1883.
Jun 20 19:19:05 wirenboard-AGPLM2T7 New client connected from 127.0.0.1 as mosqsub|22556-wirenboar (c1, k60).
Jun 20 19:19:05 wirenboard-AGPLM2T7 New connection from 127.0.0.1 on port 1883.
Jun 20 19:20:02 wirenboard-AGPLM2T7 New client connected from 127.0.0.1 as mosqpub|22557-wirenboar (c1, k60).
Jun 20 19:20:02 wirenboard-AGPLM2T7 Client mosqsub|22556-wirenboar disconnected.
Jun 20 19:20:02 wirenboard-AGPLM2T7 Client mosqpub|22557-wirenboar disconnected.
Jun 20 19:20:02 wirenboard-AGPLM2T7 New connection from 127.0.0.1 on port 1883.
Jun 20 19:20:05 wirenboard-AGPLM2T7 New client connected from 127.0.0.1 as mosqsub|22653-wirenboar (c1, k60).
Jun 20 19:20:05 wirenboard-AGPLM2T7 Client mosqsub|22653-wirenboar disconnected.
8

А покажите что есть в конфиге про логи:

cat /etc/mosquitto/*  |grep log

Если добавить в
/etc/mosquitto/mosquitto.conf

log_type error
log_type warning

То писаться “информационные” не будут. Ну, если не нужны, конечно.

9

Спасибо, помогло.

Там log_dest file /var/log/mosquitto/mosquitto.log
Однако лепило и в messages, и в daemon.log, что, согласитесь, странно.

10

И еще!
В сислоге несколько раз в минуту вот это:

CRON[14662]: (root) CMD (/usr/share/wb-daemon-watchdogs/check_wbrules.sh 2>&1 | logger -t wb-daemon-watchdogs)

Убился выяснять, кто и где добавляет это в кронтаб - НЕ СМОГ найти… Хелб.

11

Вот тут обсуждалось:

12

Верно. Так вот КТО добавляет в кронтаб эту команду? Я хочу изменить ее, чтобы она не какала в логи каждую минуту. Спасибо.

13

пакет wb-daemon-watchdogs

14

Не нашел там этой строки. Тыкнете мордочкой? Спасибо.

15

Вот тут, в postinst скрипте:

16

Кошмар. Спасибо.

17

Хотя стоп. Все равно не смог найти, где это выкорчевать на контроллере. Шайтан.
Пока сделал инит-скрипт, который удаляет это из кронтаба, но где оно добавляет-то?!

18

Непосредственно командой в крон. Истребил.

Теперь вот что. Ставил на узел контроллер весной, аптайм 24/7. Сейчас решил проверить (убрал по максимуму запись на еММС, оставил только жизненные логи и базу москиты).

#cat /sys/kernel/debug/mmc0/mmc0\:0001/ext_csd \
| python -c 'import binascii, sys; print "~%d%% wear" % (ord(binascii.unhexlify(sys.stdin.read().strip())[0x5e])*10)'

~0% wear

но

# mmc extcsd read /dev/mmcblk0 | grep -i life

eMMC Life Time Estimation A [EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_A]: 0x03
eMMC Life Time Estimation B [EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_B]: 0x01

т.е., если верить утилитке, под 30% жизни уже позади. Стоит задуматься о рамлоге?..