Вход Наше всё Теги codebook 无线电组件 Поиск Опросы Закон Понедельник
19 октября

О смысле всего сущего 0xFF Средства и методы разработки Мобильная и беспроводная связь Блошиный рынок Объявления

Микроконтроллеры PLD, FPGA, DSP AVR PIC ARM, RISC-V Технологии Кибернетика, автоматика, протоколы Схемы, платы, компоненты

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

1011589 Топик полностью

lloyd (11.06.2020 18:13, просмотров: 1036) ответил fk0 на Какими опциями ты избавишся от того, что кто-то постоянно mtime обновляет только потому, что у него там файл-флаг? Формально записи в файл нет, а запись в файловую систему с обновлением _десятков_ блоков -- раз в секунду.

Можно просто этот файл оставить в tmpfs, а rootfs сделать read-only

Ответить

- А в паделке финских студентов уже сделали 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)