Bug 23958 - Активация raid/lvm/mpath происходит слишком поздно
: Активация raid/lvm/mpath происходит слишком поздно
Status: CLOSED NOTABUG
: Sisyphus
(All bugs in Sisyphus/startup)
: unstable
: all Linux
: P3 normal
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2010-08-26 11:27 by
Modified: 2010-08-28 23:15 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2010-08-26 11:27:55
Сейчас активация raid/lvm/mpath происходит непосредственно перед монтированием
локальных FS.  Предлагаю делать это сильно раньше, например сразу после запуска
udev.

Такое чувство, что в случае когда lvm поднимается из initrd, девайсы /dev/dm-*
есть, а симлинков из /dev/mapper/ на них нет пока второй раз не запустится
vgchange.  Поэтому swap раздел у меня пытается активироваться два раза, первый
раз как /dev/dm-1, второй раз как /dev/mapper/ssd-swap.
------- Comment #1 From 2010-08-26 20:13:28 -------
(In reply to comment #0)
> Сейчас активация raid/lvm/mpath происходит непосредственно перед монтированием
> локальных FS.  Предлагаю делать это сильно раньше, например сразу после запуска
> udev.

Оно не будет работать до приведения rootfs в рабочее состояние.

> Такое чувство, что в случае когда lvm поднимается из initrd, девайсы /dev/dm-*
> есть, а симлинков из /dev/mapper/ на них нет пока второй раз не запустится
> vgchange.

Если есть ошибка, то исправлять нужно её, а не искать пути обхода.

> Поэтому swap раздел у меня пытается активироваться два раза, первый
> раз как /dev/dm-1, второй раз как /dev/mapper/ssd-swap.

Всё, чего ты хочешь добиться -- это чтобы в результате перестановки кода до
выполнения lvm_start не было ни одной попытки включить swap...
------- Comment #2 From 2010-08-26 20:20:01 -------
Чем ненормален в этот момент rootfs?
------- Comment #3 From 2010-08-26 20:25:38 -------
(In reply to comment #2)
> Чем ненормален в этот момент rootfs?

Он не проверен.  Если тебя смущает _только_ swapon, то переноси swapon.
------- Comment #4 From 2010-08-26 22:23:42 -------
Почему на _непроверенном_ корне нельзя активировать evms/raid/lvm, зато можно
- загружать фонт;
- загружать модули;
- запускать udev;
- выставлять время;
- активировать swap;
- выставлять hostname и nisdomainname;
?
------- Comment #5 From 2010-08-26 22:29:33 -------
(In reply to comment #4)
> Почему на _непроверенном_ корне нельзя активировать evms/raid/lvm, зато можно
> - загружать фонт;
> - загружать модули;
> - запускать udev;
> - выставлять время;
> - активировать swap;
> - выставлять hostname и nisdomainname;
> ?

Всё это на непроверенном корне делать нельзя, конечно, но и проверять корень,
не сделав это, тоже нельзя.  Надо как-то разорвать порочный круг.

Я не понимаю, что дает перестановка lvm_start до проверки rootfs.
------- Comment #6 From 2010-08-27 11:18:24 -------
Не до проверки rootfs, а до первой попытки активировать своп.  Как выяснилось
ничего не даёт, в /proc/mounts в любом случае будет отдаваться /dev/dm-*.

А зачем свопы активируются два раза?  Одного swapon после монтирования всех
локальных FS недостаточно?
------- Comment #7 From 2010-08-27 12:48:13 -------
(In reply to comment #6)
> Не до проверки rootfs, а до первой попытки активировать своп.

См. комментарий №3.

> Как выяснилось
> ничего не даёт, в /proc/mounts в любом случае будет отдаваться /dev/dm-*.
> 
> А зачем свопы активируются два раза?  Одного swapon после монтирования всех
> локальных FS недостаточно?

Историческая традиция: активировать своп как можно раньше, чтобы хватило памяти
на проверку файловых систем и прочие операции.  Наверное, это уже не актуально.
------- Comment #8 From 2010-08-27 13:38:55 -------
Ну в общем проблема только в том, что в случае корня не на raid/lvm и свопа на
raid/lvm своп будет активирован на втором вызове swapon, после монтирования
всех файловых систем.
------- Comment #9 From 2010-08-27 14:08:02 -------
На самом деле, как выяснилось, причина проблем, возникающих при размещении
swap-раздела на lvm, не в том, что делается попытка активировать его слишком
рано, а в несоответствии современной структуры симлинков в /dev ожиданиям
swapon.

Проверка того, что swap-устройство уже было активировано, выполняется в swapon
путём поиска имени устройства в /proc/swaps.  При этом в /proc/swaps всегда
указывается путь к реальному файлу устройства, даже если в системном вызове
swapon() было указано имя симлинка (фактически там возвращается имя открытого
файла, как для /proc/$pid/fd/*); это отличается от ситуации с /proc/mounts, где
запоминается именно строка, переданная в системный вызов mount*().  Имя файла
устройства swapon получает через libblkid; для обычных разделов /dev/sd* это
имя непосредственно указывает на файл устройства, поэтому с ними проблем нет; а
вот в случае использования lvm libblkid возвращает имя /dev/mapper/*, но там
сейчас находятся симлинки, указывающие на файлы устройств /dev/dm-*, в
результате в /proc/swaps оказывается /dev/dm-*, а swapon ищет там
/dev/mapper/*.  Некоторое время назад всё это работало правильно за счёт того,
что в /dev/mapper/* находились не симлинки, а файлы устройств, созданные lvm
самостоятельно; проблема проявилась после перехода lvm на создание файлов
устройств через udev.

Так что убирание раннего вызова swapon на самом деле полностью не решит
проблему (она лишь перестанет проявляться при обычной загрузке, но выполненный
вручную вызов swapon -a вновь приведёт к ошибкам), но может привести к
проблемам в случае, если fsck потребует много памяти.
------- Comment #10 From 2010-08-27 14:14:31 -------
(В ответ на комментарий №9)
> Так что убирание раннего вызова swapon на самом деле полностью не решит
> проблему (она лишь перестанет проявляться при обычной загрузке, но выполненный
> вручную вызов swapon -a вновь приведёт к ошибкам), но может привести к
> проблемам в случае, если fsck потребует много памяти.

Это будет исправлено. Уже готовлю патч пригодный для апстрима.