ボリューム グループのスペースが不足しています。どうすれば回復できますか?

ボリューム グループのスペースが不足しています。どうすれば回復できますか?

長い話になりますが、SVN VM (vmware server) の容量が不足しています。容量不足のためコミットできません。VM には 80 GB の仮想ドライブ (hda) が 1 つ接続されており、/boot パーティションと / 用の大きな VG (VolGroup00) があります。

古い SVN リポジトリをディスクからアーカイブして削除していますが、空き領域が戻ってきません。この領域を再び使用できるようにするには、何をする必要がありますか? 私はほとんどすべてに Linux を使用していますが、実際に LVM を操作したことがないので、何が起こっているのかはわかりません。

vgdisplay出力:

--- Volume group ---
VG Name               VolGroup00
System ID             
Format                lvm2
Metadata Areas        1
Metadata Sequence No  3
VG Access             read/write
VG Status             resizable
MAX LV                0
Cur LV                2
Open LV               2
Max PV                0
Cur PV                1
Act PV                1
VG Size               74.41 GB
PE Size               32.00 MB
Total PE              2381
Alloc PE / Size       2380 / 74.38 GB
Free  PE / Size       1 / 32.00 MB
VG UUID               dPSZpL-kFBn-HpkH-ChfO-dw9q-YGg2-qHOiQF

昨日からスペースが空いてしまいました…

df -hの出力

Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
                       72G   67G  959M  99% /
/dev/hda1              99M   15M   80M  16% /boot
tmpfs                  62M     0   62M   0% /dev/shm

lvsの出力

LV       VG         Attr   LSize  Origin Snap%  Move Log Copy% 
LogVol00 VolGroup00 -wi-ao 73.38G                              
LogVol01 VolGroup00 -wi-ao  1.00G

959M の空き容量があると表示されているのに、72G のサイズで 67G が使用されているので、まだ何か変な感じがします...

リポジトリを削除することで、スペースを取り戻しつつあります...しかし、宇宙のバランスはまだ回復していません...

答え1

ファイルを削除しても論理ボリュームのサイズは変更されません (したがって、ボリューム グループの空き領域にも影響はありません)。

ボリューム グループは「仮想ディスク」のようなもので、その上の論理ボリュームはパーティションのようなものですが、通常のパーティションよりも操作 (サイズ変更、作成、削除) がはるかに簡単です。

Kamil が言うように、作業中に「スペース不足」エラーが発生する場合、直接の障害は LVM ではありません。これは単純なファイルシステム エラーであり、 を使用してどのファイルシステムのスペースが不足しているdf -hかを特定し、そのファイルシステム上の十分なデータを削除すると、最終的にスペースが増えます。ただし、LVM では、空きスペースが大量にあるファイルシステムとまったくないファイルシステムがある場合、空きスペースが大量にある LV を縮小し、そのスペースをスペース不足の LV に割り当てることで、割り当てられたディスクをより効率的に使用できます。

ファイルシステムの縮小と拡張のプロセスは少々リスクがあります (そのためバックアップを取ってください)。また、縮小段階はマウントされていないファイルシステムで実行する必要があります (そのためシングル ユーザー モードに切り替えるのが適切で、ルート ファイルシステムを縮小することはできません。ファイルシステムがサポートしている場合 (XFS、reiser、最近の ext2/3)、オンライン拡張を行うことができます)。一般的に、プロセスは次のようになります。

  1. 領域を削除したいファイルシステムを、最終的に希望するサイズよりも少し小さいサイズにresize2fs /dev/mapper/VolGroup00-largeLV xG縮小します ( など)。少し小さく縮小する理由は、計算を間違えて LV をファイルシステムよりも小さく縮小すると、問題が発生するためです。
  2. スペースを削除したいLVを希望のサイズに縮小します(lvresize -L xG VolGroup00/largeLV
  3. その LV 上のファイルシステムを LV の新しいサイズまで拡張します。resize2fs /dev/mapper/VolGroup00-largeLV
  4. 小さすぎる LV を新しい、より大きなサイズに拡大します。lvresize -L+nG VolGroup00/smallLV
  5. 小さすぎる LV 上のファイルシステムを新しい、より大きなサイズに拡張します。resize2fs /dev/mapper/VolGroup00-smallLV

これで、どこにでも十分なスペースが確保されるはずです。

いくつかのヒント:

  • lvsすべてのLVとそのサイズを一覧表示します
  • vgsすべてのVGのサイズと空き容量を素早く表示します
  • スワップが LVM 上にある場合、マシンの負荷がそれほど高くない場合は、一時的に空き領域を確保するのに適した場所になることがよくあります。

幸運を!

答え2

/dev/sda はローカルですか、それとも SAN 上ですか? SAN 上にある場合は、希望があります。ローカルにあり、使用可能なスペースをすべて使用している場合は、ファイルを削除してディスク領域を解放する必要があります。

質問を更新し、状況をお知らせください。

編集

ああ、それは VM です! 幸運ですね (とにかくホスト マシンに空き領域がある場合)。

VM マネージャーで、必要な空き領域と同じ大きさの別の仮想ディスクを作成します。次に、そのディスク イメージを VM に提示します。

VM がそれを認識していることを確認します (表示されるかどうかを確認するには dmesg を使用します)。認識されていると仮定して、fdisk を実行し、パーティションを 1 つ作成します。

問題

 pvcreate /dev/whatever1  

ここで「何でも」は明らかにデバイスです。おそらく sdb です。1 は先ほど作成したパーティションです。この物理ボリュームの作成に問題はないはずです。

さあ、走れ

 vgextend VolumeGroupName /dev/whatever1 

vgdisplay を使用して、ボリューム グループに空き領域があるかどうかを確認できます。次に、論理ボリュームを拡張します。

 lvextend -l +100%FREE 

これにより、論理ボリュームが拡張され、ボリューム グループがいっぱいになります。

次は難しい部分です。ext3 ファイルシステムを持っていると仮定すると、ライブでオンザフライでサイズを変更できるはずです。

 resize2fs /dev/volgroup/logicalvolume 

(volgroup と logicalvolume は、/ にマウントされているものの実際のパスです)

ボリュームがマウントされているため、ライブサイズ変更を実行していることが示され、df -h を実行すると空き領域があることが示されます。

答え3

ボリューム グループの空き領域の量は変わりません。すべて、フォーマットに使用したファイル システムによって割り当てられます。ファイルを削除すると、ファイル システムからその inode エントリが削除されるだけですが、ファイル システムは引き続き領域を要求します。

ボリューム グループ内のスペースを再利用する唯一の方法は、論理ボリュームのサイズを変更するか削除することです。

しかし、あなたが説明していることは、単にディスク容量が不足しているように聞こえます。VM の出力をチェックしてdf -h、リポジトリが存在するボリュームにどれだけの空き容量があるかを確認する必要があります。

答え4

SVN サーバーを再起動してみてください。ファイルを削除してもスペースが解放されない場合は、何らかの理由でまだ使用されているはずです。これはアクティブ ログでも発生します。以前、1 時間あたり 10 MB ずつ大きくなるログがあったので、すぐにログを削除する必要がありましたが、そのログにデータを吐き出していたデーモンを再起動するまでスペースは解放されませんでした。

編集: なぜこれが起こるのか調べてみました。Linux/Unix は参照カウント ファイルを使用しているため、ファイルを開いているすべてのプロセスによって解放されるまで、ファイルは削除される可能性があります。

関連情報