私のサーバーの1つに奇妙な問題があります。ディスクスペースのほぼ半分を失いました。
df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda3 271G 122G 149G 46% /
devtmpfs 3.8G 0 3.8G 0% /dev
tmpfs 3.8G 8.0K 3.8G 1% /dev/shm
tmpfs 3.8G 8.6M 3.8G 1% /run
tmpfs 3.8G 0 3.8G 0% /sys/fs/cgroup
/dev/sda1 497M 120M 378M 24% /boot
tmpfs 778M 0 778M 0% /run/user/600
一方、duは6GBのみが使用されているとマークします。
du -hs /
6.0G /
これはログが定期的にディスクを100％まで満たすサーバーなので、最初の反応はrsyslogデーモンを再起動することでしたが、何の効果もありませんでした。また、サーバーを再起動しようとしたため、一部のファイルは削除されていますが、一部のプロセスでまだ使用されることはできません。私が探していますhttps://serverfault.com/questions/299839/linux-disk-space-missing誰かが再起動を提案しましたが、fsck役に立ちませんでした。同じページで、誰かが別のマウントポイントでファイルを参照するように提案しましたが、何もありません。もっとアドバイスを求めています。
出力fdisk：
fdisk -l /dev/sda
Disk /dev/sda: 299.5 GB, 299506860032 bytes, 584974336 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 65536 bytes / 65536 bytes
Disk label type: dos
Disk identifier: 0x000f1d8a
Device Boot Start End Blocks Id System
/dev/sda1 * 2048 1026047 512000 83 Linux
/dev/sda2 1026048 17018879 7996416 82 Linux swap / Solaris
/dev/sda3 17018880 584974335 283977728 83 Linux
lsblk出力：
lsblk -f /dev/sda
NAME FSTYPE LABEL UUID MOUNTPOINT
sda
├─sda1 xfs 78e8f824-1a2a-4c60-ab7b-6126a192932d /boot
├─sda2 swap bdbe969d-c59d-4956-ae69-71e2825f93dc [SWAP]
└─sda3 xfs a9c9da10-5e99-4a14-a207-490e3f676617 /
`xfs_quota -x -c 'free -h -b'` output:
Filesystem Size Used Avail Use% Pathname
/dev/sda3 270.7G 127.1G 143.5G 47% /
/dev/sda1 496.5M 119.0M 377.5M 24% /boot
Filesystem Size Used Avail Use% Pathname
/dev/sda3 270.7G 127.1G 143.5G 47% /
/dev/sda1 496.5M 119.0M 377.5M 24% /boot
xfs_quota -x -c 'quota -h'何も返しません。誰もクォータを設定しません。これは、同じ構成とパーティションレイアウトを使用してブランチに展開された数百のサーバーの1つですが、このサーバーにのみこの問題があります。何らかの特定の理由で定期的に最大100％を満たす唯一のディスクです。毎週または2週間に1回、いくつかのログを手動で削除します。
答え1
boot、、、、マウントポイントディレクトリの1つの下に多数のファイルが隠されているようですdev。runこのsysディレクトリは、マウントされている他のファイルシステムのためにアクセスできないことがよくあります。実行中のシステムからアクセスしてみてください。
mkdir /mnt/root
mount --bind / /mnt/root
du -hs /mnt/root/
du返された値が報告された6GBの使用量よりはるかに多い場合は、これが問題であることがほぼ確実です。これを使用して、失われたファイルが隠されている場所を識別します。
du -hs /mnt/root/{boot,dev,run,sys}
これは/mnt/root実際にはルート/ファイルシステムなので、削除やその他のファイル操作に注意する必要があることに注意してください。いずれにせよ、/mnt/rootマウントポイントとして使用できるディレクトリを直接削除しようとしないでください。
答え2
fsがどのスペースを占めているかを調べるための最良のツール（どのファイルが削除されたがまだ開いているのかわからない）は、rootfsを診断するncduことです。ncdu -qx /
再起動後も問題は解決しないため、「削除されたがまだ開いているファイル」の犠牲者ではないようです。
答え3
実行中のシステムからすべてのファイルとディレクトリにアクセスするには、rootユーザーとしてディスク使用量を確認する必要があります。
ルートファイルシステムでクォータが有効になっている可能性があります。確認するxfs_quota -x -c 'free -hi' /
ライブCD（gparted、systemrescue）で起動mount /dev/sda3 /mntし、du -csh /mnt/* そしてdf -H。
次に、/ dev / sda3をアンマウントし、/ dev / sda3でアンマウントされたxfsファイルシステムを確認しますxfs_repair -n /dev/sda3。
読むhttps://mankier.com/8/xfs_repairどのテストを実行するかをご覧ください。
答え4
構成とパーティションが同じサーバー100台のうち1台です。
fsの実際の使用量を推定できますか？ 6GBは小さすぎる？
dfGetInfostatvfs()はスーパーブロックで利用可能なブロック数を報告するため、「使用量」は計算された値です。
デフォルトでは、du各ファイルが使用するブロックとそのファイルを含むディレクトリも計算されます。
du<df ファイルシステムがあるため
ブロックは fs によって使用可能とは見なされず、
duディレクトリエントリまたはdu何らかの理由でディレクトリエントリにアクセスできません。ここで権限、ACL、SELinux、AppArmor、長いファイル名を確認してください。 https://unix.stackexchange.com/a/619878/153329
次に考えてください：
また、特定の理由で定期的にディスクを100％まで埋める唯一のソフトウェアです。毎週または2週間に1回、いくつかのログを手動で削除します。
開いているファイルを削除すると、ファイル名を持つディレクトリエントリは消えますが、inodeはそのまま残り、ファイルハンドルが閉じるとカーネルはinodeを削除してブロックを解放します。
稼働時間が高いコンピュータには別々の inode が多い可能性があるため、再起動すると便利です。
再起動時にfsckは役に立ちませんでした。
何らかの理由で、これらの分離された inode は、エラー、停電、以前のディレクトリの破損によってカーネルから削除されない可能性があるため、再起動しても役に立ちません。
xfs_repair /dev/sda3最後に、アンマウントされたファイルシステムを手動で確認することをお勧めします。
役に立たないと、ファイルシステムが破損し、xfs_repairがプリマップを正しく更新できない可能性があります。
ほとんどの場合、信頼する必要がありますdu。
次も確認してみてください。
du -hそれと比較してみてくださいdu -bh /。
まれなファイルを探す：
find / -type f -printf "%S\t%p\n" | gawk '$1 < 1.0 {print}'
fsブロックサイズより小さいファイルがたくさんある可能性があります。
xfs_info / | grep bsize
find / -type f -size -4096c | wc -l00