Bug 11133

Summary: LVM + udev = race
Product: Sisyphus Reporter: Sir Raorn <raorn>
Component: libe2fsAssignee: placeholder <placeholder>
Status: CLOSED FIXED QA Contact: qa-sisyphus
Severity: blocker    
Priority: P2 CC: glebfm, ldv, mike, placeholder, thresh, vsu
Version: unstable   
Hardware: all   
OS: Linux   

Description Sir Raorn 2007-03-17 19:51:36 MSK
/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 Sergey Vlasov 2007-03-17 21:35:14 MSK
/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 Dmitry V. Levin 2007-04-01 17:44:39 MSD
Я соберу libblkid с поддержкой libdevmapper, это должно решить проблему.
Comment 3 Dmitry V. Levin 2007-04-01 19:29:18 MSD
Should be fixed in 1.39-alt3.
Please reopen if not.
Comment 4 Sir Raorn 2007-04-02 15:45:04 MSD
Похоже, что всё в порядке:

/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 Sergey Vlasov 2007-04-02 15:58:07 MSD
Но /dev/dm-* и /dev/mapper/* всё равно цепляются случайным образом?
Comment 6 Sir Raorn 2007-04-02 17:18:25 MSD
Думаю, приоритет у dm-*, но для /usr этот dm-* ещё не создан udev'ом.