Использование udevadm для ожидания сканирования scsi для завершения внутри initramfs?

Где проблема: я использую ArchLinux с archzfs, а привязка zfs в моих initramfs иногда пытается (и не удается) импортировать пулы слишком рано, прежде чем scsi-сканирование всех дисков, используемых ZFS, будет завершено. Это приводит к сбою загрузки, поскольку zfs используется в моей системе также как корневая файловая система. Чтобы решить эту проблему, я ищу некоторую команду, которая блокирует выполнение крюка zfs (это просто скрипт пера, сохраненный и исполняемый внутри изображения initramfs) до завершения сканирования scsi.

Как это относится к udevadm: если бы я использовал linux ядро ​​до 3.6, я бы просто добавил modprobe scsi_wait_scan ; rmmod scsi_wait_scan ; modprobe scsi_wait_scan ; rmmod scsi_wait_scan ; блокировать выполнение крюка zfs до завершения сканирования scsi. Однако я использую ядро ​​4.4, и этот модуль недоступен. Я думаю использовать вместо этого udevadm settle , но я не совсем уверен, действительно ли это полезно для такого использования. Это связано с тем, что в ArchLinux уже есть крюк udev, который выполняется до привязки zfs и делает следующее:

run_hook() { msg ":: Triggering uevents..." udevadm trigger --action=add --type=subsystems udevadm trigger --action=add --type=devices udevadm settle }

Итак, следуя https://bugs.launchpad.net/ironic-python-agent/+bug/1551300, я решил вместо этого добавить две строки в zfs hook (до импорта zfs)

# Force udev to list all devices, will block until scsi scan is completed udevadm trigger --verbose --dry-run --type=devices --subsystem-match=scsi_disk udevadm settle

Имеет ли это смысл? Или я должен попробовать что-то другое? Проблема с тестированием решения заключается в том, что проблема возникает только изредка, а это значит, что даже если я перезагружу компьютер несколько раз, не увидев его снова, это не гарантирует, что проблема была исправлена. Итак, заданный здесь вопрос заключается не в том, чтобы исправить мои initramfs для меня, а для подтверждения (или отказа), может ли udevadm использоваться для ожидания завершения сканирования scsi, и если так – как.

One Solution collect form web for “Использование udevadm для ожидания сканирования scsi для завершения внутри initramfs?”

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

 bronek@gdansk ~ % cat /etc/modprobe.d/zfs.conf # Enforce synchronous scsi scan, to prevent zfs driver loading before disks are available options scsi_mod scan=sync 
  • Сочетание SSD + HDD в один быстрый, большой раздел?
  • Смешивание 4k / 512 дисков с ZFS (FreeNAS)
  • Как ZFS растет / масштабируется?
  • Сбой BSD после создания пула ZFS
  • ZFS в Linux снимок рекурсивно объема и подвыборки
  • временный файл репликации zfs
  • У ZFS для Linux над стрессом VirtualBox?
  • Что вы собираетесь делать с вашими машинами OpenSolaris?
  • Сбой umount / home (ZFS) при завершении работы
  • Загрузите небольшое изображение в формате ZFS
  • Зеркало ZFS на том же диске для резервирования?
  • Linux и Unix - лучшая ОС в мире.