выдача диска с нижней половины драйвера устройства - PullRequest
2 голосов
/ 21 марта 2011

В настройке Xen доступ к вводу-выводу с гостевых виртуальных машин проходит через привилегированный домен с именем dom0, который представляет собой просто модифицированное ядро ​​Linux, которое имеет вызовы от и до гипервизора XEN. Для блочного ввода-вывода у них есть модель разделенного драйвера, внешний интерфейс которой находится в гостевой виртуальной машине, а внутренний драйвер - в домене 0. Бэкэнд просто создает структуру «био» и вызывает submit_bio (), как в традиционном кодовом драйвере блока linux.

Моя цель здесь - проверить, есть ли какие-либо проблемы в данных, записываемых на диск (потерянные данные, незаметно поврежденные записи, неправильные записи и т. Д.). Поэтому мне нужно прочитать данные, которые были записаны на диск, и сравнить их с копией данных в кеше (это обычная функция диска, называемая «чтение после записи»). У меня вопрос: нельзя ли вызвать __bread () с уровня моего драйвера бэкэнда? Ядро вылетает при вызове __bread. Может кто-нибудь понять причину этого? Кроме того, если это невозможно, какие еще есть способы чтения определенного блока данных с диска в нижней части драйвера?

Могу ли я перехватить и клонировать биоструктуру записей, а также изменить операцию, прочитанную в моей новой биографии, и снова вызвать submit_bio ()? Я сделал это, но номер сектора в био-структуре, который возвращается обратным вызовом завершения метода submit_bio (), является случайным значением, а не теми, которые я отправил.

Спасибо.

1 Ответ

1 голос
/ 21 марта 2011

Если бы это было моей задачей, я бы сначала попытался написать новый алгоритм планирования.Начните с копирования кода планирования cfq или deadline или noop или as и начните с него работать, чтобы самостоятельно отправлять команды чтения после принятия запросов на запись.noop, вероятно, было бы легче изменить, чтобы читать сразу после записи и распространять ошибки вверх, но я не могу представить, что производительность будет очень хорошей.Но если вы используете один из других планировщиков в качестве базового, вероятно, будет гораздо сложнее сообщить об ошибке сразу после записи - возможно, пройдет несколько секунд, прежде чем чтение будет запланировано снова - так что это действительно будет толькополезен в качестве диагностического факта, а не того, что может принести пользу приложениям напрямую.

...