it-swarm.cn

重新读取分区表而不重启?

有时,当调整大小或以其他方式处理磁盘上的分区时,cfdi​​sk会说:

_Wrote partition table, but re-read table failed. Reboot to update table._

(这在其他分区工具中也会发生,因此我认为这是Linux问题而不是cfdisk问题。)为什么会这样,为什么只会发生有时,我该怎么办避免吗?

注意:请假定我实际上正在编辑的分区均未打开,未安装或正在使用中。


更新:

cfdisk使用ioctl(fd, BLKRRPART, NULL)告诉Linux重新读取分区表。到目前为止推荐的其他两个工具(_hdparm -z_ DEVICE,_sfdisk -R_ DEVICE)完全相同。另一方面,partprobeDEVICE命令似乎使用了称为BLKPG的新ioctl,可能更好。我不知道。 (如果BLKPG失败,它也会退回到BLKRRPART上。)

BLKPG似乎是“此分区已更改;这是新大小”操作,它看起来像partprobe在传递的设备上的所有分区上分别调用它,因此如果未使用各个分区,它应该可以工作。但是,我没有机会尝试。

71
Teddy

恕我直言,最可靠/最好的答案是

partprobe /dev/sdX
68
knweiss

重新读取分区表信息并不总是可行,但是请尝试

hdparm -z /dev/sda

要么

sfdisk -R /dev/sda

如果可以,/ proc/partitions中的值将更改。

19
ko-dos

在Centos7上:

根据 https://access.redhat.com/solutions/19957

你应该试试 :

partx -u <partition>

它为我工作。

10
uus

注意:请假设我实际上正在编辑的分区均未打开,未安装或正在使用中。

在这种假设下,分区表can将被成功重新扫描,并且不会出现此问题。如果您遇到该错误,那是因为分区表is当前正在使用,因此如果不创建不一致项就无法重新扫描。

8
womble

它不是基于您正在编辑的分区。

假设您只有一个硬盘(/dev/sda)和两个分区(/dev/sda1/dev/sda2),而您仅安装了一个分区(/dev/sda1)。如果您删除或更改尚未挂载的其他分区(/dev/sda2),您将收到以下错误消息:重新读取分区表失败,内核将使用旧表。

但是,如果您有两个硬盘(/dev/sda/dev/sdb)和(/dev/sdb)正在使用中。然后,您可以添加/删除/调整/dev/sdb,它们将被重新读取而没有任何问题。但是,即使在更改期间挂载了/ dev/sdb的一个分区。然后内核将继续使用旧表。

6
Saurabh Barjatiya

几天前,我(原始提问者)遇到了其他情况(包括partprobe /dev/sdX,目前已被接受且投票最高的答案)有效。 did的工作原理是:

blockdev --rereadpt /dev/sdX

(我不知道为什么这行得通,而其他人行不通,但是我很高兴它行得通,因为它使我可以在繁忙的服务器上重新启动。)

5
Teddy

我在centos 6.5 x64上;内核2.6.32。我正在测试fdisk技巧来调整大小。

/dev/sda1 /boot
/dev/sda2 /

以下所有命令均not使内核重新读取分区:

  • partprobe/dev/sda(警告:内核无法重新读取..。)
  • hdparm -z/dev/sda(BLKRRPART失败:设备或资源繁忙)
  • blockdev -rereadpt/dev/sda(BLKRRPART失败:设备或资源繁忙)
  • sfdisk -R/dev/sda(BLKRRPART失败:设备或资源繁忙)

我仍然需要重启才能使其正常工作

5
Max

卸载所有安装点后,运行Yocto 2.4:

partprobe /dev/sda 

在设备上删除分区后,仍然无法重新加载分区表。也尝试过-失败了的是:

udevadm trigger --subsystem-match=block; udevadm settle
hdparm -z /dev/sda
blockdev --rereadpt /dev/sda

所有错误均报告类似的“ BLKRRPART失败:设备或资源正忙...”错误,指示我重新启动。先前工作方法的这种失败是否可能是由于udev现在处于systemd控制之下?我按照这些思路思考:

systemctl restart systemd-udevd.service

突然我的磁盘再次可用,无需重新启动!

3
Camp Waub-O-Jeeg

您也可以尝试:

echo 1 > /sys/block/sdX/device/rescan

(但无法使用,请参见下面的评论)

1
bogdano

当类似blockdev --rereadpt /dev/sdX失败,

blockdev: ioctl error on BLKRRPART: Device or resource busy

这通常意味着内核确实仍在使用某些(旧)分区。

可能的原因/修复:

  1. sdX分区-说sdX1-仍在安装-用mount检查并卸载
  2. /dev/sdX1是软件团队的一部分-检查cat /proc/mdstat并可能停止相关的数组,例如mdadm --stop /dev/md126
  3. /dev/sdX1是LVM物理卷的一部分-使用pvdisplay/_vgdisplay检查,并可能通过vgchange停用
  4. /dev/sdX1是某些设备映射的一部分-例如通过cryptsetup-检查/dev/mapperlsblk并可能删除映射(例如cryptsetup luksClose
  5. 使用udev探测进行竞争-用ps检查正在运行的进程,并可能杀死一个

如果是一种工具-说blockdev --rereadpt通常会失败,例如(partx -uvkpartxpartprobekpartprobe)以类似的方式失败,直到根本原因得以消除。

1
maxschlepzig

kpartx -a <partition>可以在新创建的分区....上运行两次,而无需重新启动系统。

0
Kailas Kadam

对我而言,partprobeblockdev解决方案均无效。虽然,这一作品:

udevadm settle --exit-if-exists=/dev/sdb1
0
Sibi

记住要检查udev服务是否正在运行。当partprobe,hdparm,blockdev和其他各种命令似乎对/ dev /目录中可用的设备文件没有任何影响时,这特别有用。

0
kerolasa