PV в OCI

Eugene Grosbein написал(а) к Ruslan Suleimanov в Jun 20 02:15:43 по местному времени:

28 июня 2020, воскресенье, в 18:19 NOVT, Ruslan Suleimanov написал(а):

EG>>>> Первым делом надо смотреть, что показывает команда ?
EG>>>> то есть список определившихся и подключенных дисковых устройств.
RS>>> При загрузке в PV режиме Oracle Cloud предлагает замоунтиться на
RS>>> da0 их SCSI
RS>>> da0: <ORACLE BlockVolume 1.0> Fixed Direct Access SPC-4 SCSI
RS>>> device
RS>>> da0: 300.000MB/s transfers
RS>>> da0: Command Queueing enabled
RS>>> da0: 92160MB (188743680 512 byte sectors)
RS>>> uhub0: 2 ports with 2 removable, self powered
RS>>> Trying to mount root from ufs:/dev/ada0s1a [rw]...
RS>>> (da0:vtscsi0:0:0:1): READ(6). CDB: 08 00 00 01 01 00
RS>>> (da0:vtscsi0:0:0:1): CAM status: SCSI Status Error
RS>>> (da0:vtscsi0:0:0:1): SCSI status: Check Condition
RS>>> mountroot> ?
RS>>> List of GEOM managed disk devices:
RS>>> da0
RS>>> а тут я пытаюсь замоунтиться по разному:
RS>>> Trying to mount root from ufs:/dev/da0s1a []...
RS>>> Trying to mount root from ufs:/dev/ada0s1 []...
RS>>> Trying to mount root from ufs:/dev/ada0s1a []...
EG>> Тебе же сказано, что у тебя нет девайсов, кроме da0,
EG>> то есть нету da0s1a (и ada* тоже нету).
RS> в локально запущенной вирутальной машине #sysctl -a | grep kern.disks тоже
RS> показывает только ada0 cd0

Ты не понимаешь. Показания kern.disks имеют лишь косвенное
отношение к содержимому каталога /dev. Ядро монтирует
корневую файловую систему не по kern.disks, а по /dev.

"Дисковые" устройства в /dev кроме "корневых" типа da0
нынче появляются после того как GEOM "обнюхает" диск:
прочитает и распарсит таблицу разделов, причём рекурсивно:
сначала парсит /dev/da0 и создаёт /dev/da0[sp]*,
затем снова парсит свежесозданный /dev/da0s1 (например)
и если находит там BSDlabel, то создаёт /dev/da0s1* и так
далее, пока вложенные структуры не кончатся.

Лишь потом ядро будет пытаться монтировать то, что насоздавал GEOM.
В твоём случае "структуры кончаются" прямо на самом da0,
потому что таблица разделов с него не прочиталась.

EG>> Очевидно, это потому что ядро не смогло прочитать таблицу разделов,
EG>> так что разделы оно не увидело и девайсы для них в /dev не создало.
EG>> Надо бороться с исходной ошибкой чтения, без этого ничего не будет.
RS> в ядре FreeBSD опция device da по умолчанию как и SCSI.. куда копать ?

В PR 215235 прямо сказано, что провайдеры облаков по мнению traz@
криво реализуют стандарт SCSI, лишь бы работало с виндами и Linux,
и вроде как девелоперы AWS даже и не отпирались. Как обычно,
надо тестировать патч из старого PR (вдруг поможет)
и вообще продавливать доработку совместимости.

Можешь даже Ораклу завести тикет на тему нарушение стандарта SCSI :-)

Eugene
--- slrn/1.0.3 (FreeBSD)

Ruslan Suleimanov написал(а) к Eugene Grosbein в Jun 20 23:07:24 по местному времени:

Привет, Eugene!

Ответ на сообщение Eugene Grosbein (2:5006/1) к Ruslan Suleimanov, написанное 29 июн 20 в 02:15:


EG> 28 июня 2020, воскресенье, в 18:19 NOVT, Ruslan Suleimanov написал(а):

RS>> в локально запущенной вирутальной машине #sysctl -a | grep
RS>> kern.disks тоже показывает только ada0 cd0

EG> Ты не понимаешь. Показания kern.disks имеют лишь косвенное
EG> отношение к содержимому каталога /dev. Ядро монтирует
EG> корневую файловую систему не по kern.disks, а по /dev.
EG> "Дисковые" устройства в /dev кроме "корневых" типа da0
EG> нынче появляются после того как GEOM "обнюхает" диск:
EG> прочитает и распарсит таблицу разделов, причём рекурсивно:
EG> сначала парсит /dev/da0 и создаёт /dev/da0[sp]*,
EG> затем снова парсит свежесозданный /dev/da0s1 (например)
EG> и если находит там BSDlabel, то создаёт /dev/da0s1* и так
EG> далее, пока вложенные структуры не кончатся.

Я думал за структуру разделов отвечает MBR или GPT.
Тоесть MBR или GPT получает уже готовые /dev/da0[sp] или /dev/ada0[sp] ?
Я пробовал тот и тот вариант, не прошло...


EG> Лишь потом ядро будет пытаться монтировать то, что насоздавал GEOM.
EG> В твоём случае "структуры кончаются" прямо на самом da0,
EG> потому что таблица разделов с него не прочиталась.

EG>>> Очевидно, это потому что ядро не смогло прочитать таблицу
EG>>> разделов, так что разделы оно не увидело и девайсы для них в
EG>>> /dev не создало. Надо бороться с исходной ошибкой чтения, без
EG>>> этого ничего не будет.


RS>> в ядре FreeBSD опция device da по умолчанию как и SCSI.. куда
RS>> копать ?

EG> В PR 215235 прямо сказано, что провайдеры облаков по мнению traz@
EG> криво реализуют стандарт SCSI, лишь бы работало с виндами и Linux,
EG> и вроде как девелоперы AWS даже и не отпирались. Как обычно,
EG> надо тестировать патч из старого PR (вдруг поможет)
EG> и вообще продавливать доработку совместимости.

Там патч 2017 года, думаешь будет работать ?


EG> Можешь даже Ораклу завести тикет на тему нарушение стандарта SCSI :-)

Добавил в критический тикет! Ждем! :-)





WBR, Ruslan Suleimanov.
Telegram: @rsuleimanov
--- GoldED+/FreeBSD/..I LIKE UNIX EVERYDAY..

Eugene Grosbein написал(а) к Ruslan Suleimanov в Jun 20 10:47:27 по местному времени:

28 июня 2020, воскресенье, в 23:07 NOVT, Ruslan Suleimanov написал(а):

EG>> Ты не понимаешь. Показания kern.disks имеют лишь косвенное
EG>> отношение к содержимому каталога /dev. Ядро монтирует
EG>> корневую файловую систему не по kern.disks, а по /dev.
EG>> "Дисковые" устройства в /dev кроме "корневых" типа da0
EG>> нынче появляются после того как GEOM "обнюхает" диск:
EG>> прочитает и распарсит таблицу разделов, причём рекурсивно:
EG>> сначала парсит /dev/da0 и создаёт /dev/da0[sp]*,
EG>> затем снова парсит свежесозданный /dev/da0s1 (например)
EG>> и если находит там BSDlabel, то создаёт /dev/da0s1* и так
EG>> далее, пока вложенные структуры не кончатся.
RS> Я думал за структуру разделов отвечает MBR или GPT.

Так и есть.

RS> Тоесть MBR или GPT получает уже готовые /dev/da0[sp] или /dev/ada0[sp] ?
RS> Я пробовал тот и тот вариант, не прошло...

Всё ещё не понимаешь. Ошибка чтения это уровень ниже,
уровень протокола SCSI. Хоть MBR, хоть GPT таблицы должны прочитаться
с диска для начала, а у тебя ядро с диска вообще ничего не может
прочитать своим драйвером. Само ядро читается загрузчиком
не через ядерный драйвер, так как на этапе чтения ядра оно ещё не работат.
Загрузчик использует виртуализированные сервисы UEFI или BIOS для чтения файлов.

А как только стартует ядро, оно уже использует только свой драйвер da(4),
а он начинает использовать SCSI и выдаёт ошибку чтения.

EG>> В PR 215235 прямо сказано, что провайдеры облаков по мнению traz@
EG>> криво реализуют стандарт SCSI, лишь бы работало с виндами и Linux,
EG>> и вроде как девелоперы AWS даже и не отпирались. Как обычно,
EG>> надо тестировать патч из старого PR (вдруг поможет)
EG>> и вообще продавливать доработку совместимости.
RS> Там патч 2017 года, думаешь будет работать ?

Да тот код наверняка мало менялся с тех пор, патч вполне может приложиться.

EG>> Можешь даже Ораклу завести тикет на тему нарушение стандарта SCSI :-)
RS> Добавил в критический тикет! Ждем! :-)

Eugene
--
А ученый уподобляется обученному слону, которого погонщик поставил перед
преградой. Он пользуется силой разума, как слон --- силой мышц, подчиняясь
приказу. Это необычайно удобно: ученый отныне готов на все, так как ни за
что уже не отвечает.
--- slrn/1.0.3 (FreeBSD)