Linuxの奇妙なディスクがいっぱいある問題について話します

文書ディレクトリ

一、無視された隠しファイル

1、認識swapfile

2、処理提案

二、未解放の削除ファイル

1、duおよびdfが一致しない

2、処理提案

三、マウントによる懸案

1、消えた空間

2、処理提案

2.1解決方法

2.2テスト検証

2.3アドバイス

Linuxディスクがいっぱいの問題については、duでクリーンアップ可能な大きなファイルを検索し、一時的に削除してディスクの使用を率先して下げることで、ディスクの書き込みを継続できるだけ早く保証することが一般的です.
しかし、処理効果が異なる場合もあり、du/dfの結果は戸惑うかもしれない.
次に、次のいくつかの作業で遭遇した奇妙なディスクフルの問題を共有します.
一、無視された隠しファイル
1、swapfileを認識する
Linuxの交換ファイルswapfileの発生シーンは一般的で、隠しファイルの形で存在するため、ここでは主にswapfileのような隠しファイルについて話します.
vimでファイルを開くと、バッファ内のコンテンツをバックアップするための.swpの一時的な非表示交換ファイルが生成されます.
ファイルが正常に閉じられていない場合(端末を直接閉じたり、パソコンの電源を切ったりするなど)、.swpファイルは削除されず、このファイルでファイルを復元することができます.(正常に閉じると、このファイルは削除されます.また、ファイルを読み込むだけであれば、.swpファイルは生成されません)
また、vimが予期せぬ終了後にファイルの二次編集を再開すると、古い.swpファイルが保持され続け、新しい.swoの一時的な非表示ファイルが生成されます.
二次編集中にvimが異常に終了した場合、新しい一時隠しファイル.swn、.swm、 .swlが生成され続けます...
2、処理提案
一部の非表示ファイルのディスク使用量も大きいです.

:/tmp # ll -rth | grep G
total 17.7G
-rw------- 1 xxxx users 17.6G 2020-02-12 18:27 .sqlkfJTFl.swp

そのため、大きな隠しファイルでディスクがいっぱいになる場合がありますが、これらの隠しファイルが見つからないと、不思議で疑問に思ってしまいます.
したがって、ディスクがいっぱいであることを確認するときに、vim -rを実行することによって、すべての一時的な交換ファイルのサイズを確認し、チェックすることができます.あるいはls -lhaを通じてすべての隠しファイルを列挙してサイズを見ます.
より乱暴に、swapfileという特性を残したくない場合は、swapfileをオフにすることを考慮することができます.

vim /etc/vimrc   
#       
set noswapfile   #             ；

しかし、これは書類の損失が許容できる場合に限られることに注意してください.ファイル損失を許容できない場合は、swapfileを開くことをお勧めします.

vim /etc/vimrc   
#       
set swapfile   #             ；

二、未解放の削除ファイル
1、duとdfが一致しない
隠しファイル要因が排除された場合、duのサイズが奇妙であることがわかります.例えば、duはディスクがいっぱいではないことを発見しましたが、dfはディスクの使用率が100%であることを発見しました.
これはまたどんな原因ですか?
この場合、削除されたファイルがあるのではないかと疑われ、プロセスによってハンドルが解放されていないため、これらのファイルは削除されているが、確かに見えないが、ディスク領域を占めている.これにより、duとdfのディスク使用結果が一致しない場合があります.
2、処理提案lsof | grep deletedを実行すると、ディスク領域が解放されていないファイルとプロセスが見つかり、対応するプロセスを再起動することで、削除されたファイルが占有する領域を解放する目的が達成されます.
この投稿「ホットファイルを空にする一般的なエラー操作」では、「削除されたファイルがディスクを占有している」というシーンと処理方法について説明しています.
また、この場合、削除されたファイルを解放していないpidを見つけた後、kill pidを直接通過して削除されたファイルを解放する目的を達成する可能性があることを特に注意してください.この方法では、削除されたファイルを解放してディスク領域を解放することができますが、この方法は副作用があり、危害は大きくても小さくてもかまいません.
オフライン環境でこのように操作すると、影響は一般的に大きくありません.しかし、生産環境でこのように操作すれば、故障する可能性があります.
本番環境のプログラムが何らかのバグのためログファイルを解放せず、時間分割で書き込まれるログファイルには期限切れの削除メカニズムがあると仮定します.そうすると、サーバに期限切れの削除ログファイルが大量に存在し、ディスクがいっぱいになるリスクが発生するまでディスク領域を占有していることがわかります.
では、このときkill pidで直接処理すれば、生産環境のオンラインプログラムを直接乾かすことになります.この結果は、このプログラムがデーモンプロセスによって引っ張られるまで、このサービスは利用できません.
三、積載による懸案
1、消えた空間ls -lhaを実行しても大きな隠しファイルが発見されなかった場合、lsof | grep deletedを実行しても解放されていない削除されたファイルは発見されなかった.
しかし、dfはルートディレクトリが100%に達しているのを見て、duから出てきたルートディレクトリの実際の使用空間は満たされていない.
これはまたどんな原因ですか?
このような場合は、最近このディスクが異常な機械を思い出して、ディスクを点検したり交換したりしたことがありますか?
ルートディレクトリにこのような奇妙な現象が発生するのは、通常、ディスクの点検/交換時(ここでは/data1を交換すると仮定する)に、新しいディスクがマウントされていないうちに/data1にデータを書き始めた場合であり、この場合、新しいディスクがマウントされていないため、データを書き込むのにルートディレクトリの空間が占有される.
その後、/data1ディスクに交換して再マウントすると、/data1に置かれていたデータがマウントディスクに表示されることもなく、ルートディレクトリのスペースを占有し続けることもできます.
そのため、このような現象が発生します:マウント後のdu /data1は大きくありませんが、マウント前の/data1ディレクトリに書き込まれたデータは実際にルートディレクトリ空間を占有しています.しかもこのデータはマウント後は見えないので発見しにくいです.
そこで、ルートディレクトリには空で消えたような空間があることに気づき、かなり奇妙です.
2、処理提案
2.1解決方法
新しいマウントディスクがいくつかのデータを隠していることをどのように確認しますか?
新しいマウントディスク/data 1 umountを落として、/data 1が占有する空間を見てみればわかります.umountがbusyをプロンプトした場合:実行できます.

fuser -kmvi /data1 && umount /data1

解決する.
アンインストールすると、/data 1ディレクトリの下に確かに大量のファイルがあることがわかります.削除した後、mount -aに再マウントし、ルートディレクトリが消えたディスク領域は、一般的に戻ってきます.
2.2テスト検証
まだ不安なら、データを整理して再度マウントした後、簡単にテストできます.

dd if=/dev/zero of=/data1 bs=1M count=20000

/data1に約20 Gのデータを書いて、次のルートディレクトリの空間が影響を受けているかどうかを観察します.
影響を受けなければ問題解決を説明します!
2.3アドバイス
ルートディレクトリのような奇妙な問題に対して、ディスクを交換するたびにマウント動作を再開する前に、ルートディレクトリのスペースの使用状況を確認することをお勧めします.誤ってデータが書き込まれた場合は、直ちにクリーンアップしてから、新しいディスクのマウントを行う必要があります.