LVMグループでのUbuntuディスクスペースの増加はOSに反映されていません
RAID構成にいくつかのディスクを追加し、6TBから約14TBにしました。 Ubuntuサーバーの仮想マシンディスクのサイズを12TBに増やし、GPartedを使用してパーティションを元のサイズから拡張し、使用可能なすべての12TBを使用しました。
しかし、サーバーにログインすると、80％がいっぱいであると表示されます。 dfは間違っていないように見えますが、わかりません。なぜこれが変わっていないのですか？ GPartedに変更を加えたところ、成功したとのことでした。
変更と再起動後のGPartedでの私の結果は次のとおりです。
ログインしてdfを実行すると次のようになります。
ドライブが拡張されていないように見える理由はありますか？
UPDATE：この回答の指示 に従った後、私はいくつかの進歩を遂げました：UbuntuライブCDから、マウントを見つけましたポイント、マウントを解除し、e2fsckでスキャンしましたが、問題はありません。サイズを変更しようとすると、「ファイルシステムはすでに[xxxxxx]ブロックの長さです。何もすることはありません！」答えが言ったように。ここで他に何をすべきかわからない。これがLVMであるという事実はそれと関係がありますか？
LVMを使用しているため、パーティションのサイズを変更すると、LVMのサイズが大きくなります物理ボリューム。次に、そのスペースは論理ボリュームに割り当てられます。
そのスペースを使用するために既存の論理ボリュームのサイズを増やしたい場合は、lvresizeを使用します。
Sudo lvresize -L 100% /dev/mapper/gatlinburg--vg-root
…使用可能なすべてのスペースを使用して拡張します。その後ファイルシステムを拡張して、次を使用してそのスペースを使用できます。
resize2fs /dev/mapper/gatlinburg--vg-root
これを行うために何かをアンマウントする必要はありません。
デバイスがすべて拡張されている間、デバイス上のファイルシステムがスペースを埋めていないように聞こえます。修正はかなり簡単です。
ボリュームがアンマウントされていることを確認してください。
まず、/dev/sda3に接続されているボリュームをアンマウントする必要があります。質問の情報に基づいて、デバイスは/dev/sda3であると想定していますが、間違っている場合は自由に調整してください。
Sudo umount /path/to/whatever/uses/that/space
また、拡張するボリュームがシステムのメインブートボリュームである場合は、別のOSインスタンスで起動し、最初のファイルシステムのメインボリュームをそこにマウントしてから、この拡張操作全体をそこから実行する必要があることにも注意してください。このようなことが発生する理由が何であれ、ファイルシステムをマウントできないため、起動したボリュームのスペースを拡張することはできません。
ファイルシステム自体をチェック/修復します。
次に、 e2fsck を実行して、次のように/dev/sda3のファイルシステムを確認します。
Sudo e2fsck -f /dev/sda3
私はe2fsckを実行して自分なりの方法で徹底するのが好きです。ファイルシステムがクリーンで修復の必要がないことがわかっている場合は、プロセスの中核にはなりませんが、他の操作を続行する前に、ファイルシステムがクリーンであることを確認することをお勧めします。
ファイルシステムのサイズを変更します。
e2fsckが完了したら、次のように resize2fs を実行して、実際のサイズ変更プロセスに進みます。
Sudo resize2fs /dev/sda3
ここで、出力に注意してください。それがこのようなことを言うなら：
resize2fs 1.42 (29-Nov-2011)
Resizing the filesystem on…
次に、ファイルシステムを拡張する必要があり、現在拡張されていることがわかります。しかし、出力が次のようになっている場合：
resize2fs 1.42 (29-Nov-2011)
The filesystem is already [xxxxxx] blocks long. Nothing to do!
他の何かが起きている可能性があります。何？よくわかりません。しかし、resize2fsを実行することでこの問題が解決することをかなり確信しています。