перечитать таблицу разделов без перезагрузки?

<p>иногда, изменяя размер или иным образом копаясь в разделах на диске, cfdisk скажет:</p><blockquote> <p>\_<code>wrote partition table, but re-read table failed. reboot to update table.</code>\_</p> </blockquote><p>(это также происходит с другими инструментами разбиения, поэтому я думаю, что это проблема linux, а не проблема cfdisk.) почему это так и почему это происходит только <em>иногда</em>, и что я могу сделать чтобы избежать этого?</p><p>примечание: пожалуйста, предположите, что ни один из разделов, которые я редактирую, не открыт, не смонтирован и не используется иным образом.</p><hr><p>обновление:</p><p>cfdisk использует <code>ioctl(fd, blkrrpart, null)</code>, чтобы сказать linux перечитать таблицу разделов. два других рекомендованных инструмента (\_<code>hdparm -z</code>\_ <em><code>device</code></em>, \_<code>sfdisk -r</code>\_ <em><code>device</code></em>) выполняют в точности то же самое. команда <code>partprobe</code> <em><code>device</code></em>, с другой стороны, похоже, использует новый ioctl под названием blkpg, который может быть лучше; я не знаю. (он также возвращается к blkrrpart в случае сбоя blkpg.)</p><p>blkpg выглядит как операция "этот раздел изменился; вот новый размер", и он выглядел как <code>partprobe</code>, который вызывал его индивидуально на всех переданных разделах устройства, поэтому он должен работать, если отдельные разделы неиспользованными. однако у меня не было возможности попробовать это.</p>

<p>имхо самый надежный/лучший ответ</p><pre><code>partprobe /dev/sdx </code></pre>

<p>перечитывание информации таблицы разделов не всегда работает, но попробуйте</p><pre><code>hdparm -z /dev/sda </code></pre><p>или</p><pre><code>sfdisk -r /dev/sda </code></pre><p>если это работает, значения в/proc/partitions изменятся.</p>

<p><strong> в centos7: </strong></p><p><em> согласно <a href="https://access.redhat.com/solutions/199573">https://access.redhat.com/solutions/19957</a> </em></p><p>тебе стоит попробовать :</p><pre><code>partx -u <partition> </code></pre><p>это сработало для меня.</p>

<blockquote> <p>примечание: пожалуйста, предположите, что ни один из разделов, которые я редактирую, не открыт, не смонтирован и не используется иным образом.</p> </blockquote><p>учитывая это предположение, таблица разделов <em>может</em> будет успешно повторно проверена, и проблема не возникнет. если вы получаете эту ошибку, это потому, что таблица разделов <em>is</em> используется в настоящее время, и, следовательно, не может быть повторно проверена без создания несоответствий.</p>

<p>он не основан на разделе, который вы редактируете.</p><p>предположим, у вас есть только один жесткий диск (<code>/dev/sda</code>) и два раздела (<code>/dev/sda1</code>, <code>/dev/sda2</code>) и вы смонтировали только один раздел (<code>/dev/sda1</code>). если вы удалите или измените что-либо в другом разделе, который даже не смонтирован (<code>/dev/sda2</code>) вы получите ошибку, что перечитывание таблицы разделов не удалось и ядро будет использовать старую таблицу.</p><p>но если у вас есть два жестких диска (<code>/dev/sda</code>, <code>/dev/sdb</code>) и ни один из разделов (<code>/dev/sdb</code>) используются. затем вы можете добавлять/удалять/изменять размер/редактировать разделы <code>/dev/sdb</code> и они будут перечитаны без проблем. но даже если один раздел/dev/sdb был смонтирован во время изменения. тогда ядро продолжит использовать старую таблицу.</p>

<p>у меня (первоначального спрашивающего) была ситуация несколько дней назад, когда ни один из других ответов (включая <code>partprobe /dev/sdx</code>, в настоящее время принятый и получивший наибольшее количество голосов) работал. что <strong>сделал</strong> работа, однако, было это:</p><pre><code>blockdev --rereadpt /dev/sdx </code></pre><p>(я не знаю, почему это сработало, а другие нет, но я рад, что это сработало, поскольку это спасло меня от перезагрузки на занятом сервере.)</p>

<p>я нахожусь на centos 6,5 х64; ядро 2.6.32. и я проверяю трюк fdisk, чтобы изменить размер.</p><pre><code>/dev/sda1 /boot /dev/sda2 / </code></pre><p>все следующие команды <strong><em> не </em></strong> заставили ядро перечитать раздел:</p><ul> <li><strong>partprobe/dev/sda</strong> (предупреждение: ядру не удалось перечитать ....)</li> <li><strong>hdparm -z/dev/sda</strong> (сбой blkrrpart: устройство или ресурс заняты)</li> <li><strong>blockdev -rereadpt/dev/sda</strong> (сбой blkrrpart: устройство или ресурс занят)</li> <li><strong>sfdisk -r/dev/sda</strong> (сбой blkrrpart: устройство или ресурс заняты)</li> </ul><p>мне все еще нужна перезагрузка, чтобы она заработала</p>

<p>при всех несмонтированных точках монтирования работает yocto 2.4:</p><pre><code>partprobe /dev/sda </code></pre><p>не удалось перезагрузить таблицу разделов после удаления разделов на устройстве. также попробовал - и не удалось:</p><pre><code>udevadm trigger --subsystem-match=block; udevadm settle hdparm -z /dev/sda blockdev --rereadpt /dev/sda </code></pre><p>все сообщали об аналогичных ошибках "ошибка blkrrpart: устройство или ресурс занят ...", указывающие на перезагрузку. возможно, этот сбой ранее использовавшихся методов связан с тем, что udev теперь находится под контролем systemd? размышляя в том же духе, я попытался:</p><pre><code>systemctl restart systemd-udevd.service </code></pre><p>и вдруг мой диск снова доступен, <strong>без перезагрузки!</strong></p>

<p>вы также можете попробовать:</p><pre><code>echo 1 > /sys/block/sdx/device/rescan </code></pre><p>(но не сработает, см. комментарий ниже)</p>

<p>когда команда, как <code>blockdev --rereadpt /dev/sdx</code> терпит неудачу с</p><pre><code>blockdev: ioctl error on blkrrpart: device or resource busy </code></pre><p>это обычно означает, что какой-то (старый) раздел действительно все еще каким-то образом используется ядром.</p><p>возможные причины/исправления:</p><ol> <li>раздел sdx - скажем <code>sdx1</code> - все еще подключен - проверьте с помощью <code>mount</code> и размонтируйте его</li> <li><code>/dev/sdx1</code> является частью программного рейда - проверьте <code>cat /proc/mdstat</code> и, возможно, остановите соответствующие массивы, например, <code>mdadm --stop /dev/md126</code></li> <li><code>/dev/sdx1</code> является частью физического тома lvm - проверьте с помощью <code>pvdisplay</code>/<code>vgdisplay</code> и, возможно, деактивируйте с помощью <code>vgchange</code></li> <li><code>/dev/sdx1</code> является частью сопоставления некоторых устройств - например, через <code>cryptsetup</code> - проверьте <code>/dev/mapper</code> и <code>lsblk</code> и, возможно, удалите сопоставление (например, <code>cryptsetup luksclose</code>)</li> <li>состояние состязания с некоторой проверкой udev - проверьте запущенные процессы с помощью <code>ps</code> и, возможно, уничтожьте</li> </ol><p>если один инструмент - скажем <code>blockdev --rereadpt</code> обычно не схожи (<code>partx -uv</code>, <code>kpartx</code>, <code>partprobe</code>, <code>kpartprobe</code>) аналогичным образом завершают работу до тех пор, пока не будет устранена основная причина.</p>

<p><code>kpartx -a <partition></code> можно запустить два раза на только что созданном разделе .... вместо перезагрузки системы.</p>

<p>для меня ни <code>partprobe</code>, ни <code>blockdev</code> решение не сработало. хотя, этот работает:</p><pre><code>udevadm settle --exit-if-exists=/dev/sdb1 </code></pre>

<p>не забудьте проверить, что сервис udev запущен. это особенно полезно, когда partprobe, hdparm, blockdev и различные другие команды, кажется, не имеют никакого значения, какие файлы устройств доступны в каталоге/dev /.</p>