caxapa.ru :: relatime - есть. "из коробки". Но даже оно, по идее, не должно перманентно.

Cкpипaч^пророк (10.06.2020 18:20, просмотров: 754) ответил fk0 на noatime/relatime есть? А то будет перманентно писать.

relatime - есть. "из коробки". Но даже оно, по идее, не должно перманентно.

Там кода - один бинарник, загрузились и гоняем по сети байтики. После загрузки в файлову

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

... но не любой ценой.

Ответить

- Из описания задачи вообще не понятно, зачем монтировать ФС на запись. - s_h_e(11.06.2020 09:56)
  - Описания задачи и не было. Был вопрос по инструментарию диагностики. - Cкpипaч^пророк(11.06.2020 10:50)
  - Да, кстати, многие делают свой /eklmn куда монтируют jffs и пишут туда, что нужно, а остальное оказывается ro и пофигу. - fk0^{легенда}(11.06.2020 10:13)
- А кроме бинаря этого, случайно, systemd нет? Попробуй то же самое с init=/bin/sh. - fk0^{легенда}(10.06.2020 20:04)
  - Даже пробовать не буду. Бесполезное знание. - Cкpипaч^пророк(10.06.2020 23:13)
    - С чего бесполезное? Ты знаешь чем занимаются все компоненты systemd? По-моему уже никто не знает. И какая нибудь маленькая сраная часть постоянно делает touch какого-то ей очень нужного файла, где-то в /var/tmp. И ты попал на новую флешку. Кстати советую find /var -mmin -1. - fk0^{легенда}(10.06.2020 23:19)
      - Это Линукс, детка, то, что ты только что предложил за год написать с нуля, достигается правильными опциями монтирования файловой системы. Cкpипaч^пророк(84 знак., 11.06.2020 09:28)
        
        Какими опциями ты избавишся от того, что кто-то постоянно mtime обновляет только потому, что у него там файл-флаг? Формально записи в файл нет, а запись в файловую систему с обновлением _десятков_ блоков -- раз в секунду. - fk0^{легенда}(11.06.2020 10:11)
        
        Можно просто этот файл оставить в tmpfs, а rootfs сделать read-only - lloyd(11.06.2020 18:13)
        
        А в паделке финских студентов уже сделали overlay для файловых систем? Чтоб поверх ro rootfs был rw overlay, который куда-то там писался отдельно. И потом просто посмотреть, что туда написалось и сделать выводы. Вроде да, сам никогда не пользовался: - fk0^{легенда}(11.06.2020 18:32, ссылка)
        
        Docker вроде бы именно на этой фишке и работает. Но там дошли до маразма - каждая команда создает отдельный слой файловой системы. Хотя я пока не дошел до такого уровня дзена, у меня только два экземпляра ubifs для обновления. И почти наверняка долбят до неприличия флешку (собственно журналирование с ротацией) - lloyd(11.06.2020 20:56)
        
        Сделали. Люди пользуются. Но есть ощущение что и без него все в порядке, изучаю вопрос. На самом деле бессмысленно бороться за totaly readonly (как и за любой другой абсолют, к слову). Нахуя такая схизма?! А обновления накатить?Потихоньку обложил "железку" измерялками и, в общем, никакой особой драмы не наблюдаю. Cкpипaч^пророк(372 знак., 11.06.2020 19:55)
        
        overlayfs удобна тем, что при тотальном крэше rw файлухи "от неизбежных в ~~море~~ поле случайностей" ты остаешься с исходной ro rootfs, а не с кирпичем. Обновления на ядро/rootfs накатываются путем замены собственно ядра/rootfs. Обновления всего остального - обычным порядком. - LightElf(11.06.2020 20:49)
        
        Есть и другой путь. Делаем не readonly, а контроль ресурса. ~~Освободившуюся RAM используем для хранения фото котиков.~~ Достаточно несложно просигналить на базу за полгода до "окирпичивания". ~~Выезд на замену - платный.~~ Cкpипaч^пророк(127 знак., 11.06.2020 21:00)
        
        Систему нужно обновлять целиком, а не по частям. Иначе потом никто не разберется в этом конструкторе, у кого, что и какой версии стоит. А так прочитал /etc/version и сразу понял, что за хрень у клиента установлена, и что, ее, млин, надо было еще год назад обновить - lloyd(11.06.2020 21:30)
        
        Слово "нужно" слишком сильно похоже на слово "должен". У меня, наоборот, у клиента на шлюзе скорее всего, кроме прочего, крутятся десятки прикладных скриптов. Узко-специально-клиентских. Естественно они обновляются раздельно-асинхронно. - Cкpипaч^пророк(11.06.2020 21:34)
        
        В идеальном мире, где софт не содержат ошибок, а микросхемы работают строго по спецификации - оно конечно. А в реальном мире хорошо бы сохранить доступ к платке в Дальних Пердях. Чтобы зайти по SSH, отформатить флешку и заново залить свежи софты. - LightElf(11.06.2020 21:15)
        
        Стоп! Вы действительно умеете форматировать флешку, на которой лежит и /boot, и /root одновременно? (и вообще другой любой памяти, кроме еще оперативки, в системе нет?) Cкpипaч^пророк(129 знак., 11.06.2020 21:27)
        
        Мы, кажется говорили об overlayfs? На флешке два раздела: FAT и EXT3. Загрузчик подбирает с FAT-раздела ядро с вкомпиленной маленькой ramfs и запущает его. Инитскрипт чекает раздел EXT3 и если он годен - монтирует поверх своего rootfs, после чего все работает оттуда с обновленным софтом и прочим блекджеком. При этом FAT-раздел вообще не смонтирован и никто туда ничего не пишет. Если раздел EXT3 покоцан - то ничего не монтирует, дает зеленый свисток в зенит и ждет LightElf(271 знак., 11.06.2020 21:46)
        
        root кладётся в initrd в котором squashfs. Т.е. с флешки только загрузчик однажды скопирует содержимое в ОЗУ и запустит. Потом до следующего ребута флешка не нужна вообще. Я такое видел. Можно как раз обновлением всё переписать в процессе работы. Хуже, если в процессе обновления сбой, ребут, питание кончится. Но там загрузчик в отдельном разделе сидел, который со своим вторым запасным маленьким линуксом, и который умел скачивать из сети всё заново. - fk0^{легенда}(11.06.2020 21:27)
        
        Ну да, как-то так. В одном из вариантов есть три версии ядра: одна, совсем мелкая, в SPI флешке. Вторая и третья - на FAT-разделе. Загрузчик сначала пытается запустить новую версию с FAT-раздела, если не вышло - предыдущую версию с FAT-раздела, если и там облом - то мелкое ядро из SPI. А если уж и там все плохо, то загрузчик будет пытаться загрузиться по сетке. - LightElf(11.06.2020 21:53)
        
        Альтернативная загрузка... man grub или что-то другое? - Cкpипaч^пророк(11.06.2020 22:06)
        
        Вот на писюках тут всё плохо. Я не знаю как grub заставить так работать: у него есть fallback, но он предполагает запись на диск... не то. Нужен вариант: мол грузи ядро и initrd отсюда, а если контрольные суммы не сошлись -- тогда отсюда (из другого раздела, или с другого физического накопителя). У grub вроде нет, у syslinux есть ONERROR -- там можно что-то похожее сделать. - fk0^{легенда}(11.06.2020 23:20)
        
        Вроде бы U-Boot можно под писюк собрать, но это не точно - LightElf(11.06.2020 23:58)
        
        У меня U-Boot :) Писюками не занимался, про grub ничего не знаю. - LightElf(11.06.2020 22:37)
        
        ~~Дай списать :)~~ Можно пример скриптов посмотреть? - Cкpипaч^пророк(11.06.2020 22:42)
        
        Для U-Boot? Там же все очевидно. Ну вот от текущего проекта (там SPI флешка совсем мелкая, ядро не влазит). LightElf(572 знак., 11.06.2020 22:58)
        
        По факту, в файловую систему лазит только журналирование. Проблемы нужно решать - по мере их возникновения. - Cкpипaч^пророк(11.06.2020 10:36)
        
        По какому факту? Ты понимаешь, что iotop в упор не видит "коротких", да и вообще ~половины записей, он хорошо показывает только когда кто-то пишет мегабайтами (так сделано, через жопу). И что "журналирование" просто так ничего не пишет. Я тебе давал наводку: сдампить сисколлы (sysdig) и смотреть кто конкретно пишет. Но дальше начинается, линукс -- помойка, у него в API ~300+ функций и перечислить ответственные за запись не так-то просто. Искать изменённые файлы тоже дело fk0^{легенда}(821 знак., 11.06.2020 11:13, ссылка)
        
        Вот так и живем :) Что бы получить дельную инфу нужно коллегу разозлить. Спасибо :) - Cкpипaч^пророк(11.06.2020 11:37)

Кибернетика, автоматика, протоколы