fake raid + stripe. Как оно работает?

Как ОС не выполнив загрузку драйвера псевдоконтроллера на массивах raid 5 или raid 0 добирается до этого самого драйвера?

што

Как ОС не выполнив загрузку драйвера псевдоконтроллера на массивах raid 5 или raid 0 добирается до этого самого драйвера?

Не знаю как там в венде, но в Lunux'ах это достигается достаточно просто. Механизм называется initrd - по сути, это специальная псевдо-файловая система, которая загружается вместе с ядром в память, и монтируется как корневая. То есть эдакий ram-disk. А там уже есть все нужные драйвера и скрипты инициализации.

Когда initrd выполнил свою функцию по начальной минимальной инициализации оборудования - монтируется настоящая корневая система, а потом в него просто делается chroot (в обычном случае). Все недостающие драйверы уже загружаются из настоящей корневой ФС,

И да, если в образе initrd не будет нужных драйверов, чтобы получить доступ к настоящей корневой ФС, то фиг там система загрузится.

Но именно на UEFI, в теории, можно получить какой-никакой доступ и без драйверов для ОС - UEFI вроде как расширяемый, и для него тоже есть типа «драйверы» - они не завязаны на конкретную ОС. По крайней мере драйвера для разных ФС под UEFI я где-то видел в интернете (насчёт их качества и даже поддержки записи - это отдельный вопрос). Возможно и для raid'ов тоже есть.

Я не видел, правда, чтобы Linux это дело хоть как-нибудь использовал, но в теории такой вариант возможен.

Я не эксперт по UEFI, так что поправьте меня если я где не прав. (Я в деле UEFI скорее просто продвинутый пользователь, максимум, могу сделать и установить свои сертификаты для secure boot и подписать им своё ведро или UEFI-бинарник).

Ну и ещё этот самый чипсет от Intel'а и его fake raid - могут как-то эмулировать массив как стандартное дисковое устройство, и ОС сможет с ним кое-как работать пока не загрузит нормальный драйвер. Я хз как это устроено в конкретном случае. Несмотря на большой опыт администрирования Linux'ов - всякие встроенные в материнку fake raid'ы всегда избегал, и вам тоже рекомендую не пользоваться подобными поделками пока ваши данные не превратились в тыкву.

ОС сможет с ним кое-как работать пока не загрузит нормальный драйвер. Я хз как это устроено в конкретном случае.

BIOS контроллера перегружает вызовы int13h.

Я не про программный. С линуксячим проблем нет, boot в raid 1, а на нем initrd. Интересно как ведут себя интегрированные контроллеры без использования initrd.

вам тоже рекомендую не пользоваться подобными поделками пока ваши данные не превратились в тыкву.

Я не пользуюсь этими поделками, просто интересно как оно загружается на страйпах.

Это-то понятно, но тут речь про UEFI - может там это как-то более «технологично» решено, чем просто своё прерывание от контроллера fake-raid. Во всяком случае, UEFI'шный GRUB использует для доступа механизмы UEFI.

А ОС захватывает массив после загрузки драйвера?

Выше уже ответили. Вероятно, как-то так и работает. Хочется надеяться, что у UEFI есть какая-то более адекватная абстракция на этот счёт.

А всё вспомнил про int13h. Раньше еще вирусы были, которые его перехватывали.

Ну да, по идее в native mode int13h не должен работать.

Всё зависит от конкретной реализации fake-raid. Некоторые из них по сути не отличаются от программного. И в процессе загрузки ОС - драйвер dm-raid перехватывает управление на себя.

https://wiki.archlinux.org/index.php/Installing_with_Fake_RAID

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

драйвер dm-raid

Да, я немного опечатался. В случае с фейковым рейдом драйвером-то там обычный device mapper выступает, после того как по метаданным определяются параметры организации HDD для рейда.

lsi megaraid
псевдоконтроллер

Ну вообще, мегарейды разные бывают (и LSI в том числе). Некоторые поумнее большинства отписавшихся в этой теме.

Конкретно сабжевый прошивка для интеловского чипсета.

На материнках *никогда не бывает хардверных LSI.