ALT Linux Bugzilla – Full Text Bug Listing
| Summary: | Активация raid/lvm/mpath происходит слишком поздно | ||
|---|---|---|---|
| Product: | Sisyphus | Reporter: | Sir Raorn <raorn> |
| Component: | startup | Assignee: | Alexey Gladkov <legion> |
| Status: | CLOSED NOTABUG | QA Contact: | qa-sisyphus |
| Severity: | normal | ||
| Priority: | P3 | CC: | ldv, legion, mike, vsu |
| Version: | unstable | ||
| Hardware: | all | ||
| OS: | Linux | ||
|
Description
Sir Raorn
2010-08-26 11:27:55 MSD
(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... Чем ненормален в этот момент rootfs? (In reply to comment #2) > Чем ненормален в этот момент rootfs? Он не проверен. Если тебя смущает _только_ swapon, то переноси swapon. Почему на _непроверенном_ корне нельзя активировать evms/raid/lvm, зато можно - загружать фонт; - загружать модули; - запускать udev; - выставлять время; - активировать swap; - выставлять hostname и nisdomainname; ? (In reply to comment #4) > Почему на _непроверенном_ корне нельзя активировать evms/raid/lvm, зато можно > - загружать фонт; > - загружать модули; > - запускать udev; > - выставлять время; > - активировать swap; > - выставлять hostname и nisdomainname; > ? Всё это на непроверенном корне делать нельзя, конечно, но и проверять корень, не сделав это, тоже нельзя. Надо как-то разорвать порочный круг. Я не понимаю, что дает перестановка lvm_start до проверки rootfs. Не до проверки rootfs, а до первой попытки активировать своп. Как выяснилось ничего не даёт, в /proc/mounts в любом случае будет отдаваться /dev/dm-*. А зачем свопы активируются два раза? Одного swapon после монтирования всех локальных FS недостаточно? (In reply to comment #6) > Не до проверки rootfs, а до первой попытки активировать своп. См. комментарий №3. > Как выяснилось > ничего не даёт, в /proc/mounts в любом случае будет отдаваться /dev/dm-*. > > А зачем свопы активируются два раза? Одного swapon после монтирования всех > локальных FS недостаточно? Историческая традиция: активировать своп как можно раньше, чтобы хватило памяти на проверку файловых систем и прочие операции. Наверное, это уже не актуально. Ну в общем проблема только в том, что в случае корня не на raid/lvm и свопа на raid/lvm своп будет активирован на втором вызове swapon, после монтирования всех файловых систем. На самом деле, как выяснилось, причина проблем, возникающих при размещении 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 потребует много памяти. (В ответ на комментарий №9) > Так что убирание раннего вызова swapon на самом деле полностью не решит > проблему (она лишь перестанет проявляться при обычной загрузке, но выполненный > вручную вызов swapon -a вновь приведёт к ошибкам), но может привести к > проблемам в случае, если fsck потребует много памяти. Это будет исправлено. Уже готовлю патч пригодный для апстрима. |
