web-dev-qa-db-ja.com

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

時々、ディスクのパーティションをリサイズしたり、他の方法で変更したりすると、cfdiskは次のように表示します。

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

（これは他のパーティションツールでも発生するので、これはcfdiskの問題ではなくLinuxの問題だと思います。）なぜこれが発生し、なぜそれが発生するのかときどきと、何ができるかそれを避けるために？

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

更新：

cfdiskはioctl(fd, BLKRRPART, NULL)を使用して、パーティションテーブルを再度読み取るようにLinuxに指示します。これまでに推奨された他の2つのツール（_hdparm -z_ DEVICE、_sfdisk -R_ DEVICE）は正確に同じこと。一方、partprobeDEVICEコマンドは、BLKPGと呼ばれる新しいioctlを使用しているようです。知りません。 （BLKPGが失敗した場合は、BLKRRPARTにもフォールバックします。）

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

partitionfdisklinux
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

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

ハードディスクが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つのパーティションがマウントされていても。その後、カーネルは古いテーブルを使用し続けます。

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はソフトウェアraidの一部です-cat /proc/mdstatを確認し、関連するアレイを停止してください。 mdadm --stop /dev/md126
  3. /dev/sdX1はLVM物理ボリュームの一部です-pvdisplay/vgdisplayで確認し、vgchangeで非アクティブ化してください
  4. /dev/sdX1は一部のデバイスマッピングの一部です。 cryptsetup経由-/dev/mapperとlsblkを確認し、マッピングを削除してください（例：cryptsetup luksClose）
  5. いくつかのudevプローブによる競合状態-psで実行中のプロセスを確認し、おそらく1つを強制終了します

1つのツール-blockdev --rereadptが失敗した場合、通常、（partx -uv、kpartx、partprobe、kpartprobe）のような同様のツールは、根本的な原因が取り除かれます。

1
maxschlepzig

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

0
Kailas Kadam

私にとって、partprobeソリューションもblockdevソリューションも機能しませんでした。ただし、これは機能します：

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

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

0
kerolasa