まず、ファイルシステムが正常にバックアップされ、マウント解除されました。
その後、lvresizeが実行され、すでに実行中です。
lvresize --resizefs --size 1024G /dev/dbdrp/db
出力を表示します。
fsck from util-linux-ng 2.17.2
/dev/mapper/dbdrp-db: 1718907/201326592 files (0.4% non-contiguous), 92969270/805304320 blocks
resize2fs 1.41.12 (17-May-2010)
Resizing the filesystem on /dev/mapper/dbdrp-db to 268435456 (4k) blocks.
ファイルシステム出力は電子です。
[root@generic-linux-hostname ~]# df -hP
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/dbdrp-db 3.0T 310G 2.7T 11% /usr/local/oracle
物理ボリュームテーブルは次のとおりです。
PV VG Fmt Attr PSize PFree
/dev/xvdc1 dbdrp lvm2 a-- 1.50t 0
/dev/xvdd1 dbdrp lvm2 a-- 1.50t 0
サイズ変更が完了すると、仮想ハードディスクを回復するためにボリュームの1つが削除されます。
このlvresizeの進捗状況をどのように確認できますか？ 1時間実行され、多くの情報を提供していません。
とても感謝しています:)
ベストアンサー1
内部の内容がわからないので、これはオーバーシュートかもしれませんが、アイデアを得るには、次のことを試すことができます。
実行中のプロセスのPIDを取得します。
pgrep -afl resize2fs
2377 resize2fs -M /dev/vg0/lv-3
ここではresize2fs、lvresizeに変更されます（実際にサイズ変更を実行するコマンドの場合）。次に、strace -e pread64,pwrite64 -p 2377コマンドが実行するシステムコールを監視して、どこで読み書きするかを確認できます。
出力は次のとおりです。
pread64(3, "<!-- ..........................."..., 1236992, 2441878626304) = 1236992
pwrite64(3, "<!-- ..........................."..., 1236992, 181592702976) = 1236992
pread64(3, "<!-- ..........................."..., 479232, 2441880231936) = 479232
pwrite64(3, "<!-- ..........................."..., 479232, 181593939968) = 479232
マニュアルページを確認すると、その署名が次のようになり、呼び出しの最後の引数がオフセットであるか、現在読んでいるブロックのポイントであることがpread64わかります。バイトをTBに変換するssize_t pread(int fd, void *buf, size_t count, off_t offset)と2441880231936約2.2TBで、マイボリューム（下図）は3.44TB、2.2/3.34 = ~65%です。しかし、これは現在では近似値にすぎません。これは、使用可能なスペースに基づいてパーティションサイズを最小にするためです（resize2f -Mによる）。また、ext4（私の場合）は連続ブロックにデータを書き込むかどうかわからないので、ディスク全体よりも作業量が少なくなる可能性があります。
lv-3 vg0 -wi-ao---- <3.34t