Kenapa df cakera penuh tapi du tidak?

Mengapa df melaporkan cakera penuh sedangkan du tidak

df melaporkan cakera penuh manakala du tidak dapat mencari ruang tersebut kerana terdapat proses yang masih memegang fail yang telah dipadamkan. Memadamkan fail hanya membuang namanya daripada direktori. Blok data hanya akan dilepaskan apabila deskriptor fail terakhir yang merujuk kepada 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 keadaan tersebut pada VPS Ubuntu biasa dengan alatan yang sedia terpasang, mencari proses yang memegang fail melalui /proc, dan mengosongkan ruang tersebut tanpa perlu but semula. Punca lain bagi simptom yang sama adalah: 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. Jawapannya 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 ia tidak dibenarkan untuk membaca, itulah sebabnya pengguna biasa mendapat jumlah yang lebih kecil daripada 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 perhatikan.

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

df memberikan jawapan dengan 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.

Menghasilkan ketidakpadanan secara sengaja

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 sebarang 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 itu baharu bagi anda, penggantian arahan dalam bash meliputinya dengan betul. fallocate menempah blok sebenar tanpa menulisnya, 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 itu 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 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 deskriptor fail 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 deskriptor, dan %l mencetak perkara yang ditunjuk oleh pautan tersebut. ID proses ialah 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. Menyusun mengikut nombor tersebut meletakkan fail yang paling besar di kedudukan pertama.

Kemudian, kenal pasti proses di sebalik deskriptor yang berkenaan. Laluan di bahagian atas senarai tersebut 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 berapa lama ia telah berjalan. stat -L mencetak saiz dan bilangan blok yang diperuntukkan bagi inode yang dipadam. Secara bersama, ia menjawab soalan yang penting: servis manakah yang mengekalkan fail ini supaya tidak hilang.

Jika mesin sudah mempunyai lsof, sudo lsof +L1 akan menyenaraikan fail terbuka yang bilangan pautannya telah jatuh kepada sifar dan menunjukkan saiznya dalam satu jadual. Ia tidak tersedia pada imej Ubuntu yang 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 ia bukanlah langkah pertama yang wajar: 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 menghala ke inode yang sama, jadi memotong (truncate) fail tersebut akan membebaskan blok data sementara proses masih berjalan.

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

Langkah ini berfungsi dengan kemas apabila penulis membuka fail dalam mod tambah (append mode), kerana setiap penulisan seterusnya akan pergi ke penghujung fail semasa. Jika tidak, proses tersebut akan 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 ruang, jadi blok data 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 tersebut jika anda mahu saiznya bermula dari sifar juga.

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

sudo systemctl kill -s USR1 nginx

Perintah tersebut menghantar isyarat kepada mana-mana proses yang direkodkan oleh systemd sebagai proses utama unit tersebut, jadi unit yang mengisytiharkan Type= yang salah bagi cara daemonnya sebenarnya bermula boleh menghantar isyarat anda kepada proses yang tidak pernah memegang fail yang dipadam, dan ruang tersebut kekal seperti sedia ada.

Keempat, mulakan semula unit tersebut. sudo systemctl restart <unit> menutup setiap deskriptor yang dipegang oleh proses lama, jadi blok data akan kembali dengan pasti. Bagi 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. Nilainya akan kembali sepadan, dan find tidak lagi melaporkan deskriptor anda. Mengesahkan dengan perintah yang sama yang menemui masalah tersebut adalah tabiat yang wajar diamalkan.

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

Apabila jumlah dipersetujui dan cakera masih penuh

Jika df dan du -x root 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 banyak tetapi bersaiz sangat kecil.

df menolak -i dan --output dalam panggilan yang sama, jadi apabila anda mahukan kiraan mentah untuk dibaca atau diserahkan 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

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

Penyelesaiannya adalah dengan memadam atau memindahkan 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 yang sama. Mesin yang menjalankan kontena mencapai kedua-dua had ini lebih cepat daripada mesin lain, kerana lapisan imej mengandungi 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 di atasnya. Lekapkan sistem fail di atas direktori tersebut dan fail di bawahnya akan kekal di tempat asalnya: masih diperuntukkan, masih dikira oleh df, namun 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 (mount), 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 ke mana-mana: ia masih berada pada sistem fail root, dan ia akan muncul semula sebaik sahaja anda menyahlekap (unmount). Sekarang, 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 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 mengandaikan 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 tiada ruang kosong langsung adalah jauh lebih sukar untuk dibaiki. Ia juga merupakan penghalang antara anda dan risiko terkunci keluar: kunci yang ditambah ke authorized_keys pada sistem fail yang tiada ruang lagi boleh ditulis secara tidak lengkap atau langsung tidak ditulis, dan log masuk seterusnya akan memberikan ralat Permission denied (publickey) atas sebab yang tiada kaitan dengan kunci itu sendiri. tune2fs berfungsi pada ext2, ext3 dan ext4. XFS tidak mempunyai tetapan yang setara.

Di mana du mengelirukan anda secara sendirian

Empat tabiat du menghasilkan jumlah yang kelihatan salah.

• Hard links: du mengira inode sekali sahaja walaupun beberapa nama menghala kepadanya, jadi pepohon yang penuh dengan hard links melaporkan jumlah yang kurang daripada hasil tambah fail-failnya.
• Sparse files: du melaporkan blok yang sebenarnya diperuntukkan, manakala ls -l melaporkan saiz ketara. Tambahkan --apparent-size untuk melihat nombor yang satu lagi.
• Permissions: jika dijalankan sebagai pengguna biasa, du melangkau apa yang tidak boleh dibacanya dan melaporkan jumlah yang kurang. Ralat yang dicetaknya adalah ralat yang sering dialihkan oleh pengguna ke /dev/null dan tidak lagi dibaca.
• Sempadan sistem fail: tanpa -x, du / mengira setiap sistem fail yang dipasang di bawah /, jadi jumlahnya boleh melebihi apa yang dilaporkan oleh df /.

df juga mempunyai satu tabiat yang perlu diketahui. Ia melaporkan setiap sistem fail 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 mengalih keluar 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 telah 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 berada 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 cara yang betul dan sekadar meneka.

FAQ

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

Sebab yang biasa ialah fail yang telah dipadamkan semasa proses masih membukanya. Memadamkan fail akan membuang entri direktorinya, 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 /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 yang 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 pemasangan pada sistem fail tanpa ruang bebas 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 adalah cara paling bersih apabila proses membuka fail dalam mod append, kerana penulisannya sentiasa pergi ke hujung 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 lognya dengan isyarat yang dinyatakan dalam dokumentasinya, adalah penyelesaian yang tidak meninggalkan fail jarang (sparse file).

df menunjukkan ruang bebas tetapi penulisan masih gagal. Apakah sebab lain?

Periksa inode dengan df -i pada laluan yang sama, kerana sistem fail dengan blok bebas tetapi tiada inode bebas 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 /.

Mengapakah du melaporkan jumlah yang lebih besar daripada df?

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