Вопросы Теги

TAR извлечения к SD-карте и проверяет содержание впоследствии

Самая непосредственная оборотная сторона выполнения процесса в реальном времени - то, что процесс может легко исчерпать ресурсы любой процесс в системе. Результат Вашей точки зрения будет состоять в том, что компьютер абсолютно безразличен на клавиатуру, мышь и вероятно сеть, столько, сколько процесс в реальном времени использует ЦП. Это может произойти, если что-то идет не так, как надо, и процесс входит в бесконечный цикл, или даже временно, если процесс запускает продолжительное вычисление, не ожидая входа периодически. (Так, например, не выполняйте SETI@home с приоритетом в реальном времени.)

Одинокий однопоточный процесс на многоядерном ЦП, менее вероятно, вызовет эту проблему, так как существуют другие ядра, которые может использовать процесс более низкого приоритета. Но если тот процесс создаст какие-либо дочерние процессы, то они наследуют тот же приоритет в реальном времени, таким образом, вещи смогут выйти из-под контроля, если Вы не осторожны.

sched_setscheduler(2) страница справочника имеет хороший совет:

Так как не блокирующийся бесконечный цикл в процессе, запланированном под SCHED_FIFO или SCHED_RR, заблокирует все процессы с более низким приоритетом навсегда, разработчик программного обеспечения должен всегда сохранять доступным на консоли оболочка запланированный под более высоким статическим приоритетом, чем протестированное приложение. Это позволит чрезвычайное уничтожение протестированных приложений реального времени, которые не блокируются или завершаются как ожидалось. См. также описание предела ресурса RLIMIT_RTTIME в getrlimit (2).

Это должно быть оболочкой на консоли - не под Xterm, если Вы не хотите отдать весь X приоритетов в реальном времени также.

1
08.10.2013, 13:57
2 ответа

Проверять, что Вы получаете то же tar файл, Вы могли сделать (здесь с GNU tar):

cd /where/it/was/extracted &&
tar tf /path/to/file.tar |
  tar -T - --no-recursion -cf - |
  cmp - /path/to/file.tar

Обратите внимание, что это сравнивает содержание и метаданные включая владение и времена. Так же, например, если Вы не извлекли файлы как root, владение, вероятно, будет отличаться.

Вы также хотите удостовериться, что использовали ту же реализацию tar как тот, который создал tar файл.

2
27.01.2020, 23:29
  • 1
    я не уверен, что мы можем принять ту же реализацию TAR в нашем случае, так как мы не создаем rootfs.tar сами. Но спасибо, этот метод может стать полезным так или иначе. –  Rev1.0 09.10.2013, 10:08

Я сравнил бы контрольные суммы каждого файла.

Сначала rootfs папка дает следующую команду:

rootfs# find . -type f -print0 | xargs --null sha1sum --binary > ../rootfs.sum

Затем в targetfs папка, проверьте каждый файл:

targetfs# sha1sum --check <PATH_TO_SUM_FILE> | grep FAILED
1
27.01.2020, 23:29
  • 1
    Обратите внимание, что это не будет жаловаться на потенциально недостающие нерегулярные файлы или каталоги, не содержащие регулярные файлы или поврежденные метаданные (времена, владение, полномочия, расширило атрибуты...). –  Stéphane Chazelas 08.10.2013, 16:43
  • 2
    @StephaneChazelas: Я не уверен, что Вы имеете в виду. Что точно предложенное решение делает так или иначе? Создайте rootfs.sum, который содержит индивидуума sha1sum каждого файла в исходном каталоге (извлеченный tar к временному местоположению?) и затем сравнивает те контрольные суммы с содержанием новой файловой системы? –  Rev1.0 09.10.2013, 10:12
  • 3
    @Rev1.0 это - точно это. Однако, как упомянуто StephaneChazelas, это только проверит содержание файлов не их метаданные (владелец, полномочия...). Его решением мог бы быть более оптимальный вариант. –  Spack 09.10.2013, 10:57

Теги

Похожие вопросы