Centos 7のシンプロビジョニングされたルートパーティション

Centos 7のシンプロビジョニングされたルートパーティション

(私も知らない)シンプロビジョニングされたルートパーティションが薄すぎるようです。コンソールに無限のメッセージが表示され、システムが完全に応答しなくなります。

kernel: Buffer I/O error on device dm-3, logical block 2449799
kernel: lost page write due to I/O error on dm-3

最初はディスクに欠陥があると疑っていましたが、RAIDコントローラは満足しているようです。ハードリセット後、/var/log/messagesでこのgemを見つけてください。

Jan 22 02:31:31 server kernel: device-mapper: thin: 253:2: reached low water mark for data device: sending event.
Jan 22 02:31:31 server kernel: device-mapper: thin: 253:2: switching pool to out-of-data-space mode
Jan 22 02:32:31 server kernel: device-mapper: thin: 253:2: switching pool to read-only mode

/rootはシンプロビジョニングされていてスペースが不足しているようです(Centosインストールウィザードのパーティションのアイデアを受け入れたことについて自分自身を責めます)。私はシンプロビジョニングに慣れていないので、混乱した点は次のとおりです。

# lvs
  LV     VG     Attr       LSize  Pool   Origin Data%  Meta%  Move Log Cpy%Sync Convert
  pool00 centos twi-aotz-- 41.66g               100.00 46.82                           
  root   centos Vwi-aotz-- 50.00g pool00        83.33                                  
  swap   centos -wi-ao---- 16.00g

論理ボリューム「swap」と「root」を含む50GB vg「centos」にpool00があることを正しく理解していますか?それでは、ルートがdfに応じて14 GBのデータのみを使用し、合計16 GBをスワップする場合、50 GBプールのスペースが不足するのはなぜですか?

編集:スペース制約を軽減するために、パーティションスワップを完全に削除し、他の場所に作成しました。だから今:

  #lvs
  LV     VG     Attr       LSize  Pool   Origin Data%  Meta%  Move Log Cpy%Sync Convert
  pool00 centos twi-aotzM- 41.66g               100.00 46.82                           
  root   centos Vwi-aotz-- 50.00g pool00        83.33

#df -h
Filesystem               Size  Used Avail Use% Mounted on
/dev/mapper/centos-root   50G   10G   41G  20% /
devtmpfs                 7.8G     0  7.8G   0% /dev
tmpfs                    7.8G     0  7.8G   0% /dev/shm
tmpfs                    7.8G   17M  7.8G   1% /run
tmpfs                    7.8G     0  7.8G   0% /sys/fs/cgroup
/dev/sda2                497M  154M  343M  31% /boot

とにかく、パーティションの1つに10GBのデータを持つ41Gプールで、まだ「低透かし」に達しました。

答え1

他の人が同じ質問に遭遇した場合に備えて、私の答えは次のようになります。

fstrim -v -a

または

fstrim -v /

役に立つことです。ファイルシステムは、再利用するために未使用のブロックをプールに返しません(この場合は同じファイルシステムで)。

答え2

この問題は、ルートファイルシステムがシンプロビジョニング論理ボリュームにあることを確認している間に発生しました。知っておくと便利です。

あなたの質問に答える(そしてさらに説明する)ために、出力は初期ボリュームグループが最初に16Gおよびシンプロビジョニングプール論理ボリュームを使用して標準論理ボリュームとして割り当てられているように見えlvsます。出力がないと、デフォルトのメタデータ論理ボリュームのサイズを決定できません。データサイズは41.66Gです。swappool00lvs -a

その後、論理ボリュームはroot41.66Gデータボリュームの上にシンプロビジョニングされた論理ボリュームとして作成されましたが、pool0041.66Gデータボリュームの上に50Gに超過割り当て(または後で拡張)されました。おそらく、LVMはプールボリュームがいっぱいになる前に拡張されると仮定してこれを許可しましたが、そのようなことは起こりませんでした。

正しく検出されたように、ファイルシステムは廃止されたブロックをLVMに返しませんが、ブロック自体は再利用されたため、実際のファイルでは14Gしか使用しませんでしたが、LVM 27.66Gから別の14Gを割り当ててrootから削除しました。ファイルシステムを削除しましたが、実際に廃棄され、LVMに返されませんでした。したがって、基本ボリュームに十分なスペースがありませんpool00

正しく決定したとおりに実行すると、fstrim実際にファイルシステムで使用されていないブロックが削除され、LVMにそのブロックを再利用および解放できることを通知しますpool00

swap他の場所に移動したため、lvextend少なくともpool0050G(例:root

fstrimまたは、数週間ごとに実行するようにスケジュールして、使用していないチャンクを削除してください。

関連情報