Восстановление секторов, которым не соответствуют, в RAID-массиве

Для создания пустых файлов используется команда touch . С такими безумными именами, важно цитировать их правильно.

touch ";rm *;.jpg" ";rm -rf *;.jpg"

Если вы создадите файлы с таким именем на моей машине, ожидаемая продолжительность жизни будет очень короткой.:)

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

1. Изоляция памяти для процессов пользовательского пространства очень желательна - не только для защиты ядра от вредоносных программ пользовательского пространства, но и для защиты программ пользовательского пространства друг от друга. Обычно это называется виртуальной памятью . Это также облегчает реализацию пейджинга, что также желательно по другим причинам (более простая фрагментация, более простые линкеры/погрузчики и т.д.).

2. Прерывания (не все из которых находятся под управлением приложения уровня пользователя). Отказывающийся процессор также принимает «управление» от процесса (например, ожидание и т.д., которые также являются системными вызовами). Ядро может само решить отменить планирование приложения.

3. Это очень широкий вопрос. Ядро с плохо реализованными системными вызовами уязвимо. Другим способом является возможность записи в физическую память. Есть и другие уязвимости, которые могут возникнуть из-за плохо реализованных команд (например, уязвимость sysret в процессорах Intel).

4. Корневые привилегии не совпадают с привилегиями ядра. Приложение, работающее от имени пользователя root, по-прежнему использует виртуальную память, по-прежнему должно выполнять системные вызовы, по-прежнему должно подчиняться другим правилам, которые должно соблюдать любое приложение уровня пользователя.

Если вы хотите, чтобы я предоставил более подробную информацию о некоторых ответах, дайте мне знать.

Если кто-то может улучшить некоторые из ответов, пожалуйста, не стесняйтесь указать на это.

Глупый и трудоемкий метод:

Для каждого диска соберите RAID с отсутствующим диском и подключите его. Сравните все файлы этих монтировок; если вы обнаружите какие-либо различия в любом из файлов, это ваше несоответствие.

Выполните это в системе аварийного восстановления, где RAID не работает. Чтобы убедиться в отсутствии изменений в самих членах RAID, создайте для них петлевые устройства только для чтения.

# losetup --find --show --read-only /dev/diska
/dev/loop0
# losetup --find --show --read-only /dev/diskb
/dev/loop1
# losetup --find --show --read-only /dev/diskc
/dev/loop2

Сборка с отсутствующим одним диском:

# mdadm --assemble --run --readonly /dev/md42 /dev/loop0 /dev/loop1
mdadm: /dev/md42 has been started with 2 drives (out of 3).
# mount -o ro /dev/md42 loop/
# md5sum loop/file
95e3afde4229e266cb49f1d6e3fba705  file

Сборка с отсутствующим другим диском: (и сделать это для каждого диска по очереди, так что каждый диск был отсутствующим диском один раз)

# mdadm --stop /dev/md42
# mdadm --assemble --run --readonly /dev/md42 /dev/loop0 /dev/loop2
mdadm: /dev/md42 has been started with 2 drives (out of 3).
# mount -o ro /dev/md42 loop/
# md5sum loop/file
679c261d076f268a880c0fe847739e64  file

Таким образом, у вас есть другой файл. Может быть, кто-то из них правильный, вы должны решить сами.

Обнаружение адреса несоответствия напрямую было бы, безусловно, умнее; Я не знаю, можно ли заставить md дать вам эти адреса, хотя. Тогда вам все равно придется найти, к какому файлу может относиться этот адрес в вашей файловой системе. Насколько легко это можно сделать, зависит от файловой системы.