Bug 11133 - LVM + udev = race
: LVM + udev = race
Status: CLOSED FIXED
: Sisyphus
(All bugs in Sisyphus/libe2fs)
: unstable
: all Linux
: P2 blocker
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2007-03-17 19:51 by
Modified: 2007-04-02 17:18 (History)


Attachments


Note

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


Description From 2007-03-17 19:51:36
/dev/md0 (/boot) - 16M
/dev/md1 (/) - 667M
/dev/md3 (/var/lib/vz) - LVM

При загрузке fsck вываливается с руганью на /dev/.dev-253-0 (или что-то в этом
роде).  Вылечилось банальным sleep 3 после поднятия LVM.

P.S. Возможно этот баг стОит перевесить на более подходящий пакет.

23:32 <raorn> vsu: после старта LVM у меня чекалка не нашла
/dev/mapper/storage-OpenVZ AKA /dev/dm-3 AKA /dev/.dev-253-0
23:32 <vsu> raorn: и на каком основании не нашла?
23:33 <raorn> vsu: /dev/.dev-253-0
23:33 <raorn> vsu: вставил тупо sleep 3 после активации LVM и завелось
23:33 <vsu> raorn: не понял, оно что, его так обозвало?
23:34 <raorn> ну udeff наверно сначала левый файл создаёт
23:34 <raorn> а потом его переименовывает
23:34 <raorn> вот и race
23:34 <raorn> остальные разделы ма-а-а-а-аленькие
23:34 <raorn> быстро прочекались
23:34 <vsu> raorn: так при чём тут udeff? lvm же вроде сам своими кривыми лапами
в /dev лезет
23:35 <raorn> vsu: а udeff видимо dm-3 в этот момент создавал
23:35 <raorn> который по UUID находился первым
23:35 <vsu> raorn: ну и? он его в /dev создаёт, а /dev/mapper вообще не трогает
23:36 <vsu> raorn: в /dev/disk/by-uuid/* получаются симлинки в /dev/dm-*
23:36 <vsu> raorn: а в /dev/mapper/* файлы устройств отдельно лежат
23:36 <raorn> vsu: brw-r----- 1 root disk 253, 0 Mar 16 22:58 /dev/dm-0
23:36 <vsu> raorn: ну да, это udeff
23:36 <raorn> и подмонтирован у меня именно /dev/dm-0
23:37 <vsu> raorn: хм... а ты его как в fstab указал?
23:37 <raorn> /dev/mapper/storage-OpenVZ тоже есть
23:37 <raorn> vsu: по UUID
23:37 <vsu> а...
23:37 <vsu> тогда понятно
23:38 <raorn> во-о-о-от
23:38 <vsu> вот если писать /dev/mapper/storage-OpenVZ, будет работать
23:38 <vsu> правда, в df получится лажа
23:38 <raorn> дык инсталлер создал
23:38 <vsu> точнее, не совсем
23:39 <vsu> если написать /dev/storage/OpenVZ, df всё равно будет писать
/dev/mapper/storage-OpenVZ
23:39 <vsu> хотя в /proc/mounts при этом будет /dev/storage/OpenVZ
23:39 <vsu> а вот в mtab эти симлинки раскрываются
23:42  * lioka в /proc/mounts имеет и /dev/vg/vat и /dev/dm-* для lv 
23:42 <vsu> raorn: вообще не совсем понятно, что с этим делать
23:42 <raorn> в общем я сегодня-завтра развешаю багов и отпишу в рассылку
23:42 <vsu> lioka: а в fstab это в виде UUID=.... ?
23:43 <lioka> vsu: нет, LABEL, что в общем одно и тожк
23:43 <vsu> ну да, вид сбоку
23:43 <lioka> те, что dm-* -- создавались во время этого uptime
23:43 <vsu> тогда это к libblkid или как ещё называется та жопа, через которую
сделан поиск
23:44 <vsu> видимо, что первое попалось, то и цепляется
------- Comment #1 From 2007-03-17 21:35:14 -------
/dev/.dev-253-0 - это файл устройства, временно создаваемый udevd в процессе
обработки событий (например, для передачи vol_id, когда окончательное имя
устройства ещё не определено). Вероятно, проблема в том, что библиотека
libblkid, используемая для поиска устройств в случае, если в fstab задано
UUID=... или LABEL=..., перебирает все файлы устройств в /dev в поисках
подходящего, и в некоторых случаях может получить такой временный файл
устройства, созданный udevd.

Один из вариантов обхода проблемы - модифицировать libblkid, чтобы скрытые
файлы
(.*) там игнорировались (кстати, в /dev ещё может быть каталог
/dev/evms/.nodes,
устройства из которого тоже использовать нежелательно). Хотя это не спасает от
неоднозначности - при использовании lvm устройства dm присутствуют в /dev в
двух
экземплярах (/dev/dm-$NUMBER и симлинки на них, создаваемые udevd, и
/dev/mapper/$VG_NAME-$LV_NAME и симлинки /dev/$VG_NAME/$LV_NAME, создаваемые
lvm), и libblkid использует один из этих вариантов фактически случайным
образом.
Впрочем, фатальных проблем это не вызывает, но вывод команд mount и df
становится некрасивым.

Если указывать тома lvm в fstab не через UUID=... или LABEL=..., а в виде
/dev/$VG_NAME/$LV_NAME, подобные проблемы возникать не должны. Возможно, в
инсталяторе при использовании lvm стоит заполнять fstab именно таким образом.
------- Comment #2 From 2007-04-01 17:44:39 -------
Я соберу libblkid с поддержкой libdevmapper, это должно решить проблему.
------- Comment #3 From 2007-04-01 19:29:18 -------
Should be fixed in 1.39-alt3.
Please reopen if not.
------- Comment #4 From 2007-04-02 15:45:04 -------
Похоже, что всё в порядке:

/dev/dm-1 on /home type ext3 (rw,nosuid)
/dev/mapper/storage-usr on /usr type ext3 (rw,nodev,noatime)
/dev/dm-2 on /var type ext3 (rw,nosuid)

Раньше падало, видимо, на создании /dev/dm-* для /usr
------- Comment #5 From 2007-04-02 15:58:07 -------
Но /dev/dm-* и /dev/mapper/* всё равно цепляются случайным образом?
------- Comment #6 From 2007-04-02 17:18:25 -------
Думаю, приоритет у dm-*, но для /usr этот dm-* ещё не создан udev'ом.