On Mon, Apr 30, 2007 at 10:50:59PM +0300, Michael Shigorin wrote:
> On Mon, Apr 30, 2007 at 02:41:54PM +0400, Dmitry V. Levin wrote:
> > > > > > Т.е. ты предлагаешь реализовать workaround в
> > > > > > alterator-install2, сразу после alterator-vm?  Какой?
> > > > > понизить скорость до минимума сразу после начала загрузки install2.
> > > > В этот момент raid'ы ещё не активированы.
> > > А что мешает загнать e.g. 100 в
> > > /proc/sys/dev/raid/speed_limit_max вне зависимости 
> > > от того, поднимали или ещё нет?
> > Противопоказаний нет?
> 
> Не припомню.

Вообще наиболее правильным вариантом было бы исправить ядро, чтобы md
не пытался параллельно синхронизировать несколько массивов, созданных
из устройств dm.  Проблема в том, что не совсем понятно, как именно
это реализовать.

Заглядывание из md во внутреннюю структуру dm отпадает в любом случае.
У меня остаются следующие варианты:

1) Проверка rdev->bdev->bd_disk->disk_name на наличие там "dm-".

2) Проветка rdev->bdev->bd_disk->minors == 1 (в предположении, что
   устройство, не поддерживающее разбивку на разделы, вероятно,
   виртуальное (либо floppy, что можно игнорировать)) - под эту
   проверку, помимо dm, также попадают loop (что, вероятно, правильно)
   и nbd.

В любом случае придётся сделать синхронизацию dm (и других подобных
устройств) взаимоисключающей со всеми прочими устройствами (не только
с dm) - иначе всплывёт проблема в случае, когда часть md собрана из
обычных разделов, а часть - из md (такая конфигурация сейчас получится
при использовании evms в установленной системе, но с корнем на md,
который сейчас в initramfs всегда будет собираться из разделов).