web-dev-qa-db-ja.com

LVM / DRBDサイズ変更後dfが誤った情報を報告している

DRBDにマウントされたパーティションを持つDebianXenDomUがあります。このパーティションのサイズを46Gから50Gに変更する必要がありました。私は次のことをしました:

  • セカンダリノードでDRBDを停止しました:/etc/init.d/drbd stop
  • 基盤となるLVM距離を50GBに増やしました:lvresize -L 50G /lvm/device
  • DRBDを再度開始し、ディスクが同期するのを待ちました:/etc/init.d/drbd start
  • 切り替えられた予備選挙。そして、他のノードでも同じことを実行しました。
  • 現在セカンダリDRBDノードでdrbdを停止しました:/etc/init.d/drbd stop
  • 基盤となるLVMを増やしました:lvresize -L 50G /lvm/device
  • DRBDを再度開始し、ディスクが同期するのを待ちました:/etc/init.d/drbd start
  • 発行された両方のノードで:drbdadm resize drbd-device
  • プライマリノードで発行された:resize2fs /dev/drbd0

私はこの応答を受け取ります:

$ resize2fs 1.40-WIP (14-Nov-2006)
The filesystem is already 12058624 blocks long.  Nothing to do!

Drbd0とsdaデバイスの両方がfdiskを使用して、デバイスのサイズを49392123904と報告しています。これはresize2fsが言っていることと一致しています。 (12058624x4096 [ブロックサイズ])。

私の問題は、dfがディスクサイズの変更を報告していないことです。

$ df -B 4096
/dev/drbd0            11869420  11155652    110968 100% /data

私は以前にこのプロセスを実行しましたが、問題はありませんでした。足りないものはありますか?

8
thepearson

この男はそれについて素敵なハウツーを書いた:

http://theitdepartment.wordpress.com/2008/05/30/howto-resize-a-xen-drbd-lvm-vbd/

2
Marnix

二次/一次の役割をいじる必要はありません。 1.両側のLVMサイズ変更2.プライマリ側:drbdadmサイズ変更リソース(これによりメタデバイスも更新されます)

/ proc/drbdを見ると、進行中の新しい部分の再同期が表示されます。そうでない場合は、両側で「drbdadmadjustRESOURCE」を試してください。

次に、プライマリ側の/ dev/drbd/by-res/RESOURCEを使用して、マウントされていないファイルシステムのサイズを変更します。

0
Nils