Kenapa df cakera penuh tapi du tidak?

Mengapa df melaporkan cakera penuh sedangkan du menunjukkan sebaliknya

df melaporkan cakera penuh manakala du tidak menemui ruang tersebut kerana terdapat proses yang masih memegang fail yang telah dipadamkan. Memadamkan fail hanya membuang namanya daripada direktori. Blok data hanya akan dibebaskan apabila deskriptor fail terbuka terakhir yang menghala ke inode tersebut ditutup. du menyemak nama fail, jadi ia tidak mengira fail tersebut. df bertanya kepada sistem fail tentang jumlah blok yang diperuntukkan, jadi ia tetap mengira fail yang sudah tidak mempunyai nama itu.

Panduan ini menunjukkan cara menghasilkan semula situasi tersebut pada VPS Ubuntu biasa dengan alatan yang sedia terpasang, mencari proses yang memegang fail tersebut melalui /proc, dan membebaskan ruang tanpa perlu but semula. Punca lain bagi simptom yang sama adalah seperti berikut: jadual inode yang tidak mempunyai entri kosong, fail yang tersembunyi di bawah titik lekap (mount point), dan blok yang dikhaskan untuk root.

Jalankan setiap arahan dan baca output anda sendiri. Nilai yang dipaparkan bergantung pada cakera anda, jadi bandingkan keadaan sebelum dan selepas pada mesin anda sendiri dan bukannya membandingkan dengan angka yang dicetak dalam panduan.

Perbezaan antara kiraan df dan du

df (disk free) meminta setiap sistem fail yang dilekapkan untuk memberikan perakaunan sendiri: berapa banyak blok yang wujud, berapa banyak yang diperuntukkan, dan berapa banyak yang bebas. Ia tidak pernah membuka direktori. Jawapan yang diberikan merangkumi setiap blok yang diperuntukkan, termasuk blok yang dimiliki oleh fail yang tidak mempunyai entri direktori yang merujuk kepadanya.

du (disk usage) melakukan perkara sebaliknya. Ia bermula pada laluan yang anda berikan, membaca direktori, melakukan stat pada setiap entri yang ditemui, dan menjumlahkan blok-blok tersebut. Fail yang tidak mempunyai nama adalah halimunan kepadanya. Begitu juga dengan mana-mana direktori yang tidak dibenarkan untuk dibaca, itulah sebabnya pengguna biasa mendapat jumlah yang lebih kecil berbanding root. Jalankan du di bawah sudo sebelum anda membuat sebarang kesimpulan daripada perbandingan tersebut.

Dua pilihan adalah penting setiap kali anda membandingkan kedua-duanya.

• -x mengekalkan du pada satu sistem fail. Tanpanya, du / akan masuk ke dalam setiap sistem fail yang dilekapkan di bawah / dan menghasilkan jumlah yang tidak pernah diukur oleh df /.
• -s mencetak satu baris ringkasan bagi setiap argumen dan bukannya satu baris bagi setiap direktori.

Ini memberikan pasangan arahan untuk dijalankan secara bersebelahan pada sistem fail yang anda perlukan.

df -h /
sudo du -xhs / 2>/dev/null

df memberikan jawapan serta-merta. du mengambil masa beberapa minit pada sistem fail yang besar, kerana ia melakukan stat pada setiap fail sepanjang proses tersebut. Apabila kedua-dua jumlah tersebut jauh berbeza, dan du dijalankan sebagai root dengan -x, ruang yang hilang itu diperuntukkan kepada sesuatu yang tidak mempunyai nama.

Sengaja menghasilkan ketidakpadanan

Lakukan ini pada VPS ujian. Semua arahan di bawah menggunakan bash dan coreutils, jadi tiada perisian perlu dipasang.

Rekodkan keadaan permulaan sistem fail yang memegang /var/tmp.

cd /var/tmp
df -h .
df --output=used -B1 .

Arahan kedua mencetak bait yang digunakan tanpa pembundaran, yang menjadikan semakan pada akhir nanti tepat.

Sekarang, cipta satu fail. Saiznya diambil daripada ruang bebas yang dilaporkan oleh mesin itu sendiri, supaya demonstrasi ini sesuai dengan apa jua saiz cakera yang anda miliki.

free=$(df --output=avail -B1 . | tail -n 1)
fallocate -l $((free / 10)) ghost.bin
ls -l ghost.bin
df -h .

$(...) ialah penggantian arahan (command substitution): shell menjalankan arahan di dalamnya, dan outputnya menjadi nilai bagi free. Jika sintaks ini baharu bagi anda, penggantian arahan dalam bash menerangkannya dengan betul. fallocate menempah blok sebenar tanpa menulis data ke dalamnya, itulah sebabnya ia selesai dengan serta-merta. Pada sistem fail yang tidak menyokongnya, arahan tersebut akan gagal, dan head -c $((free / 10)) /dev/zero > ghost.bin melakukan tugas yang sama dengan menulis bait tersebut keluar.

Bandingkan df -h . ini dengan yang anda rekodkan tadi. Lajur yang digunakan (used) telah bertambah dan lajur yang tersedia (available) telah mengecil.

Sekarang, pastikan fail tersebut dibuka oleh proses lain, kemudian padamkannya.

sleep infinity < ghost.bin &
holder=$!
rm ghost.bin
ls -l ghost.bin
df -h .
sudo du -xhs . 2>/dev/null

Redireksi adalah kunci utama. sleep infinity < ghost.bin & memulakan proses latar belakang yang input standardnya ialah fail tersebut, jadi shell membuka fail itu dan menyerahkan deskriptor kepada sleep, yang memastikannya kekal terbuka. $! memegang ID proses bagi kerja latar belakang tersebut. rm kemudian membuang nama fail tersebut sementara deskriptor masih terbuka.

Baca outputnya. ls tidak dapat mencari fail tersebut kerana namanya sudah tiada. du kembali ke kedudukan asal kerana ia menyemak berdasarkan nama. df tidak berubah kerana blok-blok tersebut masih diperuntukkan. Sistem fail dan pepohon direktori kini tidak lagi sepadan, dan jurang antara keduanya ialah fail yang baru sahaja anda padamkan.

Mencari proses yang memegang fail yang telah dipadam

Setiap file descriptor yang terbuka muncul di bawah /proc/<pid>/fd/ sebagai pautan simbolik kepada fail yang dirujuknya. Apabila fail telah dinyahpaut (unlinked), kernel menandakan sasaran pautan tersebut sebagai dipadam. Oleh itu, mencari pemegang bermakna mencari pautan yang sasarannya membawa penanda tersebut.

sudo find /proc/[0-9]*/fd -lname '*(deleted)' -printf '%p -> %l\n' 2>/dev/null

-lname memadankan sasaran pautan simbolik dan bukannya namanya, %p mencetak laluan descriptor, dan %l mencetak destinasi pautan tersebut. ID proses adalah elemen kedua bagi laluan yang dicetaknya. Jalankan ia dengan sudo, kerana jika tidak, anda hanya boleh membaca /proc/<pid>/fd untuk proses anda sendiri. Ubah hala stderr akan membuang gangguan daripada proses yang tamat semasa find sedang berjalan.

Pelayan yang sibuk memegang beberapa fail yang dipadam pada bila-bila masa, dan kebanyakannya bersaiz kecil serta tidak berbahaya. Isih fail tersebut mengikut saiz supaya hanya fail yang penting berada di bahagian atas.

sudo bash -c 'for fd in /proc/[0-9]*/fd/*; do
  target=$(readlink "$fd" 2>/dev/null) || continue
  case "$target" in
    *"(deleted)") echo "$(stat -Lc %s "$fd" 2>/dev/null) $fd $target" ;;
  esac
done' | sort -rn | head

stat -L mengikuti pautan ke inode itu sendiri, jadi %s melaporkan saiz fail yang tidak lagi mempunyai nama. Mengisih berdasarkan nombor tersebut meletakkan fail yang paling besar di kedudukan pertama.

Kemudian, kenal pasti proses di sebalik descriptor tersebut. Laluan di bahagian atas senarai itu membawa kedua-dua nombor yang anda perlukan, jadi masukkan nombor tersebut ke dalam pemboleh ubah terlebih dahulu, dengan menggantikan PID dan N dengan apa yang dicetak oleh senarai anda sendiri.

pid=PID
n=N
ps -o pid,user,etime,args -p "$pid"
sudo stat -L "/proc/$pid/fd/$n"

ps menamakan program dan menunjukkan tempoh ia telah berjalan. stat -L mencetak saiz dan jumlah blok yang diperuntukkan bagi inode yang dipadam. Bersama-sama, ia menjawab soalan yang penting: servis manakah yang mengekalkan fail ini.

Jika mesin sudah mempunyai lsof, sudo lsof +L1 akan menyenaraikan fail terbuka yang jumlah pautannya telah jatuh kepada sifar dan menunjukkan saiznya dalam satu jadual. Ia tidak tersedia pada imej Ubuntu minimum, dan memasang pakej pada sistem fail yang tiada ruang kosong boleh menyebabkan kegagalan, jadi kaedah /proc adalah versi yang sentiasa berfungsi.

Kosongkan ruang tanpa but semula

But semula memang menyelesaikan masalah, namun itu bukan langkah pertama yang betul: ia menghentikan servis dan menghapuskan bukti. Terdapat empat pilihan yang lebih lembut, mengikut urutan untuk dicuba.

Pertama, salin data keluar jika anda masih memerlukannya. Membaca laluan deskriptor akan membaca inode yang sedang aktif.

sudo cp /proc/<pid>/fd/<n> /root/recovered.log

Ini adalah satu-satunya keadaan di mana fail yang dipadam mudah untuk didapatkan semula, itulah sebabnya memulihkan fail yang dipadam dengan rm -rf bermula dengan bertanya sama ada sesuatu proses masih memegang fail tersebut dalam keadaan terbuka. Sebaik sahaja deskriptor terakhir ditutup, laluan tersebut akan hilang.

Kedua, kosongkan fail melalui deskriptor. Laluan /proc menuju ke inode yang sama, jadi memotong (truncate) fail tersebut akan membebaskan blok sementara proses masih berjalan.

sudo truncate -s 0 "/proc/$pid/fd/$n"
df -h /

Ini berfungsi dengan kemas apabila penulis membuka fail dalam mod tambah (append mode), kerana setiap penulisan seterusnya akan pergi ke penghujung fail semasa. Apabila ia tidak dilakukan sedemikian, proses tersebut mengekalkan offset penulisan lamanya, jadi penulisan seterusnya akan mendarat jauh ke dalam fail dan mencipta semula fail tersebut dengan lubang di bahagian hadapan. Lubang tidak diperuntukkan, jadi blok kekal bebas dan df mengekalkan ruang yang baru dikembalikan. Apa yang muncul semula hanyalah saiznya sahaja: jalankan sudo stat -L "/proc/$pid/fd/$n" sekali lagi selepas proses menulis, dan ia akan melaporkan saiz lama di sebelah kiraan blok yang tidak lagi sepadan dengannya. Mulakan semula proses apabila anda mahu saiznya bermula dari sifar juga.

Ketiga, minta servis untuk membuka semula lognya. Daemon yang fail lognya telah dipadamkan di bawahnya adalah versi sebenar yang biasa bagi masalah ini. Banyak daemon membuka semula fail log mereka apabila menerima isyarat: nginx menggunakan SIGUSR1 dan rsyslog menggunakan SIGHUP. Semak dokumentasi untuk daemon yang anda hadapi dan jangan meneka, kerana isyarat yang salah dihantar kepada daemon yang salah akan menghentikannya.

sudo systemctl kill -s USR1 nginx

Keempat, mulakan semula unit tersebut. sudo systemctl restart <unit> menutup setiap deskriptor yang dipegang oleh proses lama, jadi blok tersebut akan kembali dengan pasti. Untuk demonstrasi di atas, pemegangnya ialah sleep yang anda mulakan sendiri, jadi menamatkannya sudah memadai.

kill $holder
df -h .
df --output=used -B1 .
sudo find /proc/[0-9]*/fd -lname '*(deleted)' -printf '%p -> %l\n' 2>/dev/null

Bandingkan bait yang digunakan dengan nilai yang anda rekodkan sebelum anda mencipta fail tersebut. Ia kembali sepadan, dan find tidak lagi melaporkan deskriptor anda. Mengesahkan dengan arahan yang sama yang menemui masalah tersebut adalah tabiat yang wajar dikekalkan.

Memerhatikan nilai itu berubah adalah lebih mudah daripada menjalankan df secara manual berulang kali. watch mengulangi arahan pada selang masa tetap dan mencetak semula output di tempat yang sama, jadi watch df -h / menunjukkan perubahan pada lajur yang digunakan apabila ruang tersebut kembali.

Apabila jumlah dipersetujui dan cakera masih penuh

Jika df dan root du -x bersetuju antara satu sama lain, tiada fail yang dipadam terlibat. Punca-punca yang selebihnya adalah berbeza dari segi jenis, dan setiap satunya mempunyai pemeriksaan tersendiri.

Kehabisan inode, bukan kehabisan blok

Inode menyimpan metadata bagi satu fail. ext4 mencipta bilangan inode yang tetap apabila sistem fail dibina, jadi sistem fail boleh kehabisan inode walaupun masih mempunyai blok kosong. Fail baharu akan gagal dicipta walaupun df -h menunjukkan ruang masih ada.

df -h /
df -i /

Perintah pertama mengira blok dan perintah kedua mengira inode. Bandingkan lajur penggunaan bagi setiap satunya. Penggunaan blok yang rendah dan penggunaan inode yang mencapai had bermakna masalahnya ialah bilangan fail yang sangat kecil dalam jumlah yang sangat besar.

df menolak -i dan --output dalam panggilan yang sama, jadi apabila anda mahu kiraan mentah untuk dibaca atau diberikan kepada perintah lain, pilih medan inode mengikut nama dan jangan sertakan -i.

df --output=itotal,iused,iavail,ipcent /

Lajur tersebut membawa perakaunan yang sama seperti yang dicetak oleh df -i, dalam bentuk yang boleh anda asingkan.

Cari fail tersebut dengan mengira entri dan bukannya bait.

sudo du --inodes -x -d 1 / 2>/dev/null | sort -rn | head

Ulang perintah yang sama satu tahap ke bawah pada direktori yang berada di kedudukan teratas, sehingga anda sampai ke pepohon yang mencipta fail-fail tersebut. Jika du anda tidak menyokong --inodes, maka sudo find /var -xdev -type f | wc -l akan mengira subpepohon dengan cara yang perlahan.

Penyelesaiannya ialah memadam atau memindahkan fail-fail tersebut. Anda tidak boleh menambah inode pada sistem fail ext4 yang sedia ada, kerana bilangannya ditetapkan pada masa mkfs, jadi untuk meningkatkannya anda perlu mencipta semula sistem fail dan melakukan pemulihan daripada sandaran. XFS memperuntukkan inode mengikut keperluan, jadi ia tidak menghadapi had tetap dengan cara yang sama. Mesin yang menjalankan kontena mencapai kedua-dua had ini lebih cepat daripada mesin lain, kerana lapisan imej menyimpan banyak fail kecil. Pada mesin tersebut, membersihkan penggunaan cakera Docker pada VPS adalah penyelesaian khusus, dan ia menuntut semula ruang yang jauh lebih banyak daripada imbasan umum pada sistem fail.

Ruang tersembunyi di bawah titik lekap (mount point)

Sesuatu direktori boleh menyimpan fail sebelum apa-apa dilekapkan padanya. Lekapkan sistem fail di atas direktori tersebut dan fail di bawahnya kekal di tempat asal: masih diperuntukkan, masih dikira oleh df, dan tidak lagi boleh dicapai melalui nama. du tidak dapat melihat fail tersebut kerana titik lekap melindunginya.

Tunjukkan perkara ini dengan tmpfs, yang tidak memerlukan cakera tambahan. Bahagian ini memerlukan mesin yang membenarkan anda melakukan proses lekap, jadi ia berfungsi pada KVM VPS.

sudo mkdir -p /srv/covered
sudo cp /etc/services /srv/covered/
ls /srv/covered
sudo mount -t tmpfs tmpfs /srv/covered
ls /srv/covered
sudo umount /srv/covered
ls /srv/covered

ls di tengah menunjukkan direktori kosong. Salinan tersebut tidak pergi ke mana-mana: ia masih berada pada sistem fail root, dan ia akan muncul semula sebaik sahaja anda menyahlekap (unmount). Kini, bayangkan satu servis yang telah menulis log ke laluan tersebut selama sebulan sebelum seseorang melekapkan volum di atasnya.

Untuk mencari fail sebenar pada pelayan yang sedang berjalan, lekapkan sistem fail root buat kali kedua di lokasi lain. Bind mount menunjukkan satu sistem fail tanpa sistem fail lain yang dilekapkan di dalamnya.

sudo mkdir -p /mnt/rootcheck
sudo mount --bind / /mnt/rootcheck
sudo du -xhs /mnt/rootcheck/* 2>/dev/null | sort -h
sudo umount /mnt/rootcheck

Apa-apa yang muncul dalam senarai tersebut tetapi tidak berada di bawah laluan biasa bermakna ia tertimbus di bawah titik lekap. Nyahlekap bind mount tersebut apabila anda selesai, atau du yang dijalankan kemudian tanpa -x akan mengira fail yang sama sebanyak dua kali.

Blok yang dikhaskan untuk root

ext4 memperuntukkan sebahagian bloknya untuk pengguna root, supaya cakera yang penuh tidak menghalang root daripada log masuk dan membaiki mesin. Proses yang dijalankan sebagai pengguna biasa akan mencapai had tersebut terlebih dahulu, sementara df masih menunjukkan sedikit ruang. Baca tetapan pada sistem fail anda sendiri dan jangan hanya menganggap nilai lalai.

dev=$(df --output=source / | tail -n 1)
sudo tune2fs -l "$dev" | grep -i 'block count'

Perintah tersebut mencetak jumlah kiraan blok dan kiraan blok yang dikhaskan dalam unit yang sama, jadi nisbah antara keduanya adalah terus. df melaporkan lajur tersedia sebagai ruang yang masih boleh digunakan oleh pengguna biasa, itulah sebabnya hasil tambah ruang yang digunakan dan ruang tersedia adalah lebih kecil daripada saiz keseluruhan. Jurang tersebut adalah rizabnya.

Ubah tetapan tersebut dengan sudo tune2fs -m <percent> "$dev". Perubahan ini terpakai serta-merta dan tidak memerlukan remount. Mengurangkan rizab pada sistem fail data yang berasingan adalah munasabah. Pada sistem fail root, tinggalkan ruang yang mencukupi supaya root masih boleh menulis, kerana sistem fail root yang langsung tidak mempunyai ruang kosong adalah jauh lebih sukar untuk dibaiki. tune2fs berfungsi pada ext2, ext3 dan ext4. XFS tidak mempunyai tetapan yang setara.

Sebab du memberikan maklumat yang mengelirukan

Empat tabiat du menghasilkan jumlah yang kelihatan tidak tepat.

• Hard links: du mengira inode sekali sahaja walaupun beberapa nama merujuk kepadanya, jadi pepohon yang penuh dengan hard links melaporkan jumlah yang lebih kecil daripada hasil tambah fail-failnya.
• Sparse files: du melaporkan blok yang diperuntukkan secara sebenar, manakala ls -l melaporkan saiz ketara. Tambahkan --apparent-size untuk melihat angka yang satu lagi.
• Permissions: jika dijalankan sebagai pengguna biasa, du akan melangkau apa yang tidak boleh dibacanya dan melaporkan jumlah yang kurang. Ralat yang dicetaknya sering dialihkan ke /dev/null oleh pengguna, menyebabkan mesej tersebut tidak lagi dibaca.
• Filesystem boundaries: tanpa -x, du / mengira setiap filesystem yang dipasang di bawah /, jadi jumlahnya boleh melebihi apa yang dilaporkan oleh df /.

df juga mempunyai satu tabiat yang perlu diketahui. Ia melaporkan setiap filesystem secara berasingan, jadi jalankannya pada laluan tepat yang disasarkan oleh penulisan yang gagal. /boot yang berasingan akan penuh mengikut jadualnya sendiri apabila pakej kernel terkumpul, dan membuang kernel lama pada Ubuntu merupakan tugas yang berbeza daripada mengosongkan ruang pada /.

Prosedur kerja untuk insiden sebenar

1. Jalankan df -h <path> dan df -i <path> pada sistem fail yang disasarkan oleh penulisan yang gagal, bukan pada / secara automatik.
2. Jalankan sudo du -xh -d 1 <mountpoint> 2>/dev/null | sort -h, kemudian masuk ke dalam direktori yang paling besar.
3. Jika du tidak dapat menjelaskan apa yang dilaporkan oleh df sebagai ruang yang digunakan, cari /proc untuk fail yang telah dipadam tetapi masih dibuka.
4. Jika kedua-duanya menunjukkan nilai yang sama, lakukan bind mount pada sistem fail tersebut di lokasi lain dan cari fail yang tersembunyi di bawah titik lekap (mount point).
5. Jika penggunaan inode yang mencapai had, kira bilangan fail dan bukannya bait.

Setiap langkah di atas mempunyai arahan yang outputnya boleh anda baca. Itulah perbezaan antara membaiki masalah ini dengan tepat berbanding hanya meneka.

FAQ

Mengapa df menunjukkan cakera penuh sedangkan du menemui ruang yang jauh lebih kecil?

Sebab lazimnya ialah fail yang dipadamkan semasa proses masih membukanya. Memadamkan fail akan membuang entri direktori tersebut, jadi du tidak mempunyai nama untuk dilayari dan berhenti mengiranya. Inode dan bloknya kekal diperuntukkan sehingga deskriptor terakhir ditutup, dan df mengira blok yang diperuntukkan. Cari dalam /proc/<pid>/fd untuk pautan simbolik yang sasarannya ditandakan sebagai dipadamkan, dan anda akan menemui fail tersebut serta proses yang memegangnya. Sebelum mempercayai perbandingan tersebut, pastikan anda menjalankan du sebagai root dan dengan -x, kerana pengguna biasa akan melangkau direktori yang tidak boleh dibacanya secara senyap.

Bagaimanakah cara mencari fail yang dipadamkan tetapi masih terbuka tanpa lsof?

Gunakan rekod deskriptor terbuka milik kernel sendiri. sudo find /proc/[0-9]*/fd -lname '*(deleted)' -printf '%p -> %l\n' 2>/dev/null menyenaraikan setiap deskriptor yang menghala ke fail tanpa nama, dan ID proses terletak di dalam laluan yang dicetaknya. sudo stat -Lc %s pada salah satu laluan deskriptor tersebut melaporkan saiznya, jadi anda boleh menyusunnya dan memilih yang penting. Ini tidak memerlukan sebarang pakej, yang penting kerana memasang pakej pada sistem fail yang tiada ruang kosong boleh gagal.

Bolehkah saya mengosongkan ruang tanpa mematikan proses?

Kadangkala boleh. sudo truncate -s 0 /proc/<pid>/fd/<n> mencapai inode yang sama melalui deskriptor dan melepaskan bloknya semasa proses masih berjalan. Ini paling bersih apabila proses membuka fail dalam mod append, kerana penulisannya sentiasa pergi ke penghujung semasa. Jika tidak, offset penulisan kekal di tempat asalnya dan penulisan seterusnya mencipta semula fail dengan lubang di bahagian hadapan, jadi saiz yang dilaporkan kembali meningkat sementara blok di bawah lubang kekal bebas. Memulakan semula unit, atau menghantar isyarat kepadanya untuk membuka semula log dengan isyarat yang dinamakan dalam dokumentasinya, adalah penyelesaian yang tidak meninggalkan fail jarang (sparse file).

df menunjukkan ruang kosong tetapi penulisan masih gagal. Apa lagi puncanya?

Periksa inode dengan df -i pada laluan yang sama, kerana sistem fail dengan blok kosong tetapi tiada inode kosong akan menolak fail baharu. Periksa sama ada penulisan dijalankan sebagai pengguna bukan root pada sistem fail ext4 di mana hanya blok simpanan yang tinggal, yang akan ditunjukkan oleh sudo tune2fs -l pada peranti tersebut. Pastikan anda membaca sistem fail yang disasarkan oleh penulisan tersebut, kerana /boot atau /var yang berasingan akan penuh secara bebas daripada /.

Mengapa du melaporkan jumlah yang lebih besar daripada df?

du tanpa -x akan melintasi setiap sistem fail yang dipasang (mounted) di bawah laluan yang anda berikan, jadi ia menjumlahkan beberapa sistem fail manakala df menerangkan satu sistem fail sahaja. Bind mounts memburukkan lagi keadaan, kerana fail yang sama dikira sekali di bawah setiap laluan ia muncul. Tambahkan -x untuk mengekalkan du pada satu sistem fail sahaja, dan berikan df laluan yang sama, supaya kedua-dua arahan menerangkan perkara yang sama.