У меня есть диск на сервере, который я перехожу в группу томов LVM. Раньше использовалось традиционное разбиение диска DOS, hdb[1-5]
.
Я размонтировал все файловые системы из hdb
, отключите своп, используя hdb
, удалил VG меньшего размера на устройстве и перешел к его переразбивке с помощью fdisk, удалил существующие разделы и создал 2 раздела, но после записи Linux отказался перечитать таблицу разделов. Попытка снова использовать hdparm -z
отчеты: BLKRRPART failed: Device or resource busy.
Я проверил следующие места, чтобы убедиться, что устройство и его разделы нигде не указаны:
Но cat /proc/partitions
все еще перечисляет разбиение, и hdparm -z /dev/hdb
все еще дает мне устройство занято.
Есть ли что-то, что мне не хватает, или секретное место, о котором я еще не знаю, чтобы найти то, что все еще держится на моем блочном устройстве? и, что более важно, как я могу освободить его, чтобы перезагрузить таблицу разделов?
FWIW, в этом конкретном случае я могу просто перезагрузить сервер без особого беспокойства, но это меня раньше мучило, и мне любопытно, есть ли лучший способ.
(Edit: добавлена более точная формулировка) (Edit: детали повторного разбиения)
Обновление: я использовал partprobe /dev/hdb
, и это действительно изменило ситуацию: в / dev / hdb1, / deb / hdb [3-5] больше нет, а partprobe сообщает Error: Error informing the kernel about modifications to partition /dev/hdb1 -- Device or resource busy.
<- конкретно про hdb1. hdb1 раньше был физическим томом (PV) в группе томов LVM (VG), но я vgremove + pvremoved em до того, как я переразбил ...
Обновление 2: FWIW, я до сих пор не исправил эту проблему, к счастью, это не срочно. Я узнал, что partprobe использует новый вызов API, поэтому казалось, что он что-то делал раньше. Я до сих пор не нашел простого и эффективного способа, с учетом устройства и его старших / младших номеров, выяснить, какие ресурсы (ядро или пользовательское пространство) его используют. Любые идеи?
Попробуйте использовать фьюзер
fuser -vam /dev/hdb1
Эдди fuser -vam /dev/hdb1
Пример был по сути верным, но не обладал некоторой полнотой. В моем случае я столкнулся с аналогичной проблемой при восстановлении файлов у кого-то с последнего диска массива raid1, где раздел, содержащий данные, находился в LVM.
В этом случае я начал photorec
чтобы проверить диск, увидел, что есть группа томов, а затем закрыл терминал, работающий photorec
. Без моего ведома, photorec
все еще держался за /dev/mapper/vg0-lv0
. Итак, в будущем попробуйте использовать fuser
, но на содержании /dev/mapper/
fuser -vam /dev/mapper/*
Это все еще, вероятно, не лучший ответ, но не забудьте попытаться проверить любые файлы в / dev /, которые также могут каким-либо образом отображаться на блочное устройство, которое вы пытаетесь использовать.
lsof
это команда, которую вы ищете. Обычно вы хотите передать его в grep с точкой монтирования.
пример lsof | grep var
перечислит все процессы, у которых есть открытые файлы, в которых путь или имя файла содержат "var"
Каков вывод команды mount
. Не уверен, что это применимо к вашей ситуации, но я знаю, что использовал привязать крепления несколько раз. Размонтирование исходной файловой системы из bind-mount не размонтирует bind-mount. В этом случае вывод mount не очень полезен для того, чтобы вы знали, что происходит.