(私も知らない)シンプロビジョニングされたルートパーティションが薄すぎるようです。コンソールに無限のメッセージが表示され、システムが完全に応答しなくなります。
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です。swap
pool00
lvs -a
その後、論理ボリュームはroot
41.66Gデータボリュームの上にシンプロビジョニングされた論理ボリュームとして作成されましたが、pool00
41.66Gデータボリュームの上に50Gに超過割り当て(または後で拡張)されました。おそらく、LVMはプールボリュームがいっぱいになる前に拡張されると仮定してこれを許可しましたが、そのようなことは起こりませんでした。
正しく検出されたように、ファイルシステムは廃止されたブロックをLVMに返しませんが、ブロック自体は再利用されたため、実際のファイルでは14Gしか使用しませんでしたが、LVM 27.66Gから別の14Gを割り当ててroot
から削除しました。ファイルシステムを削除しましたが、実際に廃棄され、LVMに返されませんでした。したがって、基本ボリュームに十分なスペースがありませんpool00
。
正しく決定したとおりに実行すると、fstrim
実際にファイルシステムで使用されていないブロックが削除され、LVMにそのブロックを再利用および解放できることを通知しますpool00
。
swap
他の場所に移動したため、lvextend
少なくともpool00
50G(例:root
。
fstrim
または、数週間ごとに実行するようにスケジュールして、使用していないチャンクを削除してください。