再起動せずにパーティションテーブルを再読み込みしますか？

ディスク上のパーティションのサイズを変更したり、いじくり回したりすると、cfdiskは次のように言います。

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

（これは、他のパーティション分割ツールで起こるので、私は、これは、Linuxの問題ではなく、cfdiskの問題であると思っています。）これはなぜある、そしてなぜそれが唯一起こるん時々、私はそれを避けるために何ができるのでしょうか？

注：私が実際に編集しているパーティションは、開かれていない、マウントされていない、または使用されていると仮定してください。

更新：

cfdiskはioctl(fd, BLKRRPART, NULL)、パーティションテーブルを再読み込みするようLinuxに指示するために使用します。これまでに推奨された他の2つのツール（hdparm -z DEVICE、sfdisk -R DEVICE）はまったく同じことを行います。partprobe DEVICEこのコマンドは、他の一方で、良いかもしれないBLKPGと呼ばれる新しいIOCTLを使用しているようです。知りません。（BLKPGが失敗すると、BLKRRPARTにフォールバックします。）

BLKPGは「このパーティションが変更されました。これが新しいサイズです」操作のようpartprobeで、渡されたデバイス上のすべてのパーティションで個別に呼び出されるように見えたので、個々のパーティションが使用されていない場合は動作するはずです。しかし、私はそれを試す機会がありませんでした。

私見最も信頼できる/最良の答えは

partprobe /dev/sdX

パーティションテーブル情報の再読み取りは常に機能するとは限りませんが、試してください

hdparm -z /dev/sda

または

sfdisk -R /dev/sda

動作する場合、/ proc / partitionsの値が変更されます。

Centos7の場合：

https://access.redhat.com/solutions/199573によると

試してみてください ：

partx -u <partition>

それは私のために働いた。

注：私が実際に編集しているパーティションは、開かれていない、マウントされていない、または使用されていると仮定してください。

その仮定を考えると、パーティションテーブルを正常に再スキャンでき、問題は発生しません。このエラーが発生しているのは、パーティションテーブルが現在使用されているためであり、矛盾を発生させずに再スキャンすることはできません。

編集しているパーティションに基づいていません。

1つのハードディスク（/dev/sda）と2つのパーティション（/dev/sda1、/dev/sda2）のみがあり、1つのパーティション（/dev/sda1）のみをマウントしたとします。マウントされていない他のパーティション（/dev/sda2）を削除または変更すると、パーティションテーブルの再読み込みに失敗し、カーネルが古いテーブルを使用するというエラーが表示されます。

ただし、2つのハードディスク（/dev/sda、/dev/sdb）があり、（/dev/sdb）のパーティションがどれも使用されていない場合。その後、パーティションの追加/削除/サイズ変更/編集/dev/sdbを行うと、問題なく再読み込みされます。ただし、変更中に/ dev / sdbの1つのパーティションがマウントされた場合でも。その後、カーネルは古いテーブルを使用し続けます。

私（元の質問者）は、数日前に他の回答（partprobe /dev/sdX、現在受け入れられ、最も投票数の多い回答を含む）のいずれも機能しなかった状況にありました。何やった仕事を、しかし、これは：

blockdev --rereadpt /dev/sdX

（これがなぜ機能し、他の機能が機能しなかったのかはわかりませんが、使用中のサーバーでの再起動を省いたため、機能したことを嬉しく思います。）

私はcentos 6.5 x64を使用しています。カーネル2.6.32 そして、サイズ変更するfdiskトリックをテストしています。

/dev/sda1 /boot
/dev/sda2 /

次のコマンドはすべて、カーネルの再読み取りパーティションを作成しませんでした。

• partprobe / dev / sda （警告：カーネルの再読み込みに失敗しました....）
• hdparm -z / dev / sda（BLKRRPARTが失敗しました：デバイスまたはリソースがビジーです）
• blockdev -rereadpt / dev / sda（BLKRRPARTが失敗しました：デバイスまたはリソースがビジーです）
• sfdisk -R / dev / sda（BLKRRPARTが失敗しました：デバイスまたはリソースがビジーです）

動作させるには再起動が必要です

すべてのマウントポイントがマウント解除された状態で、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

そして突然、再起動せずにディスクが再び利用可能になりました！

次のようなコマンドが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/sdX1LVM物理ボリュームの一部である- pvdisplay/ vgdisplayでチェックし、場合によっては非アクティブ化するvgchange
4. /dev/sdX1例えば経て-いくつかのデバイスのマッピングの一部であるcryptsetup-チェック/dev/mapperし、lsblkそしておそらくマッピングを削除（例cryptsetup luksClose）
5. いくつかのudevプローブによる競合状態-実行中のプロセスをチェックしps、場合によっては強制終了します

1つのツールならば-と言うblockdev --rereadpt（のような通常と同様のものを失敗したpartx -uv、kpartx、partprobe、は、kpartprobe根本的な原因が解消されるまで）、同様の方法で失敗します。

また試すことができます：

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

（ただし、動作しません。以下のコメントを参照してください）

kpartx -a <partition> システムを再起動する代わりに、新しく作成したパーティションで2回実行できます。

udevサービスが実行されていることを確認してください。これは、partprobe、hdparm、blockdev、およびその他のさまざまなコマンドが/ dev /ディレクトリで使用可能なデバイスファイルに違いをもたらさないように見える場合に特に役立ちます。

私どちらの場合partprobeやblockdevソリューション働いていました。ただし、これは機能します：

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

「man oracleasm-scandisks」のマンページを読むと、次のテキストに注意してください。oracleasmは、実行するすべてのスキャンのソースとして/ proc / partitionsを使用しています。スキャンディスクを実行する前に、/ proc / partitionsにrawデバイスをリストする必要があります。/ etc / sysconfig / oracleasmに配置するScanorderおよびScanexcludeパラメーターは、/ proc / partitions（!!!!）にある名前に関連しています。

---------- man oracleasm-scandisks ------ ...

スキャンの実行方法スキャンは4つの基本段階で進行します。

   First, the list of disks to scan is created. If disks were specified on the command line, this is the list.
   If not, /proc/partitions is read, and each block device is added, subject to the -o and -x options.

   Second, the partition tables of each disk in the scan are reloaded unless the -s option was specified. Any
   disks that no longer exist are dropped.

   Third, the list of disks is recreated based on the new partition tables.

   Finally, each disk in the list is checked to see if it is marked for ASM use. Disks that are marked are
   instantiated.