Temu Duga Linux: Mengapakah df dan du Menunjukkan Penggunaan Cakera yang Berbeza?

Gesaan dan Konteks Berkenaan

Pada jam 02:00, satu aplikasi mula menerima ENOSPC semasa menulis di bawah /var. Hos melaporkan:

$ df -B1 /var
Filesystem          1B-blocks         Used  Available Use% Mounted on
/dev/nvme0n1p3    214748364800 210453397504          0 100% /var

$ sudo du -x -B1 -s /var
126701535232  /var

$ df -i /var
Filesystem          Inodes   IUsed    IFree IUse% Mounted on
/dev/nvme0n1p3    20000000 4200000 15800000   21% /var

Nilai yang dibundarkan ialah 200 GiB jumlah keseluruhan, 196 GiB digunakan oleh df, dan 118 GiB boleh dicapai melalui du, meninggalkan jurang ruang digunakan sebanyak 78 GiB. Output inod menolak kehabisan inod sebagai punca langsung. Perkhidmatan tersebut adalah tanpa keistimewaan, hos tidak boleh dibut semula, dan tiada fail boleh dialih keluar sehingga pemilik dan tujuannya diketahui.

Ini ialah soalan penyelesaian masalah pengeluaran Linux. Jawapan yang paling kukuh tidak bermula dengan memadam laluan fail terbesar. Ia terlebih dahulu membuktikan bahawa kedua-dua alatan memerhatikan sistem fail, ruang nama (namespace), masa, unit, dan skop capaian yang sama; kemudian ia menjelaskan peruntukan mana yang boleh wujud di luar pohon direktori yang kelihatan dan memilih tindakan pemulihan yang difahami radius impaknya (blast radius).

Perkara yang Dinilai oleh Penemu Duga

Isyarat pertama ialah model pengukuran yang betul. df meminta statistik blok keseluruhan daripada sistem fail yang dilekapkan. du menyusuri fail dan direktori yang dinamakan serta menganggarkan blok yang diwakili oleh entri yang boleh dicapainya. Kedua-duanya mengukur set yang berkaitan tetapi berbeza. Peruntukan besar yang dipegang oleh fail yang tidak dipautkan (unlinked file) atau tersembunyi di bawah direktori yang dilekap tindih (over-mounted) kekal dalam jumlah sistem fail walaupun penelusuran semasa tidak dapat menamakannya.

Isyarat kedua ialah kawalan skop. Membandingkan df /var dengan du /var tanpa sekatan, menjalankan satu perintah di dalam bekas (container), mengabaikan ralat kebenaran, atau membandingkan sampel yang diambil semasa penulisan pantas boleh menghasilkan percanggahan palsu. Calon harus menyelaraskan sasaran lekap, ruang nama lekap, sempadan sistem fail, unit bait, keistimewaan, dan tetingkap pemerhatian sebelum menentukan punca.

Isyarat ketiga ialah tindak balas insiden yang selamat. lsof +aL1 /var boleh mengenal pasti fail terbuka dengan kiraan pautan kurang daripada satu pada sistem fail tersebut, tetapi outputnya adalah bukti dan bukannya kebenaran untuk mematikan proses atau memotong (truncate) deskriptor. Jawapan yang kukuh mengenal pasti pemilik perkhidmatan, mengesahkan deskriptor fail dan peranti, mengutamakan pembukaan semula log yang disokong aplikasi atau mula semula secara tertib (graceful restart), dan mengesahkan kedua-dua penebusgunaan cakera dan kesihatan aplikasi.

Isyarat keempat ialah memisahkan punca yang kelihatan serupa. Blok yang diperuntukkan khas bagi ext4 mengurangkan ruang yang tersedia kepada penulis tanpa keistimewaan dan boleh menyebabkan Size - Used melebihi Avail; ia tidak menjelaskan mengapa 78 GiB dikira sebagai digunakan oleh df tetapi tidak wujud dalam penelusuran du pada sistem fail yang sama. Kehabisan inod juga boleh mengembalikan ENOSPC, tetapi penggunaan inod sebanyak 21% dalam gesaan menolak cabang tersebut. Salin-semasa-tulis (copy-on-write snapshots), pemampatan, dan kuota memerlukan alatan khusus sistem fail dan bukannya perintah ext4 yang disalin secara membuta tuli.

Isyarat terakhir ialah penutupan. Jawapan harus mewujudkan set bukti sebelum dan selepas, menjelaskan julat bait yang ditebus guna, mengesahkan bahawa penulis membuka semula laluan fail yang dimaksudkan, memeriksa pertumbuhan deleted-open yang berulang, dan menambah baik pemutaran log (log rotation) atau pemantauan perubahan lekapan. Peratusan yang lebih rendah dalam df sahaja tidak membuktikan bahawa aplikasi itu sihat atau bahawa data telah dipelihara.

Soalan untuk Dijelaskan Sebelum Menjawab

• Adakah kedua-dua perintah berjalan dalam ruang nama lekap yang sama? Jika satu berjalan pada hos dan satu lagi dalam

ruang nama bekas atau perkhidmatan, /var mungkin merujuk kepada lekapan yang berbeza. Siasatan mesti memasuki ruang nama proses yang terjejas atau kekal pada hos secara sengaja.

• Laluan tepat yang manakah gagal dan sistem fail manakah yang mengandungi laluan tersebut? findmnt -T memetakan laluan arbitrari

kepada lekapannya. Lekapan bersarang atau lekap paut (bind mount) mengubah perkara yang harus dibandingkan antara df dan du.

• Adakah sampel diambil bersama dengan unit dan keistimewaan yang sama? Log yang berkembang pesat boleh berubah

antara perintah, pembundaran yang boleh dibaca manusia menyembunyikan perbezaan yang lebih kecil, dan direktori yang tidak boleh dibaca menyebabkan du tanpa keistimewaan terkurang kira.

• Apakah sistem fail dan lapisan storan yang terlibat? ext4, XFS, Btrfs, ZFS, sistem fail tindanan (overlay), snapshot

LVM, dan snapshot volum awan mendedahkan kawalan perakaunan dan pemulihan yang berbeza.

• Adakah kekurangan itu dalam blok data, inod, atau kuota? df -i, alatan kuota, dan ralat aplikasi

membezakan cabang masalah. Memadam satu fail besar tidak menyelesaikan kehabisan inod, dan blok global percuma tidak mengatasi kuota pengguna atau projek.

• Tindakan pemulihan manakah yang dibenarkan secara operasi? Isyarat buka semula log, muat semula tertib (graceful reload), failover,

atau tetingkap penyelenggaraan pendek mempunyai risiko ketersediaan yang berbeza. Pemotongan deskriptor kecemasan memerlukan pemilikan yang jelas dan perancangan rollback.

• Berapa banyak ruang penimbal yang mesti dipulihkan, dan pada bila? Sasaran menentukan sama ada untuk mengekang penulisan,

memperluas volum, mengalihkan trafik (fail over), atau menebus guna peruntukan yang diketahui terlebih dahulu. Ia tidak mewajarkan pemadaman data yang tidak diketahui.

Rangka Jawapan 30 Saat

“Saya akan membekukan tindakan pemusnahan terlebih dahulu dan membandingkan laluan, sistem fail, ruang nama lekap, masa, keistimewaan, dan unit bait yang sama menggunakan findmnt, df -B1, dan sudo du -x -B1. Dengan penggunaan inod pada 21%, saya akan mengukur jurang blok 78 GiB dan memeriksa lsof +aL1 /var untuk fail yang telah dipadamkan pautannya tetapi masih dibiarkan terbuka oleh proses. Jika ada satu yang menjelaskan jurang tersebut, saya akan mengesahkan PID, deskriptor, peranti, dan pemilik perkhidmatannya, kemudian menggunakan laluan buka semula log aplikasi atau mula semula secara tertib dan mengesahkan bahawa ruang tersebut kembali. Jika tidak, saya akan memeriksa direktori yang dilekap tindih, ralat kebenaran, serta metadata atau snapshot khusus sistem fail. Blok simpanan khas ext4 menjelaskan ketiadaan ruang bagi pengguna tanpa keistimewaan, bukan jurang ruang digunakan 78 GiB. Saya akan menutupnya dengan mengulangi pengukuran dan memeriksa penulisan aplikasi, log, dan keberulangan.”

Penerokaan Mendalam Langkah demi Langkah

Mulakan dengan menjadikan perbandingan boleh dihasilkan semula. Dapatkan laluan yang gagal, ruang nama semasa, sumber lekap, jenis sistem fail, statistik blok, statistik inod, dan jumlah du secara berdekatan dari segi masa:

readlink -f /var
findmnt -T /var -o SOURCE,FSTYPE,OPTIONS,TARGET
df -B1 /var
df -i /var
sudo du -x -B1 -s /var

-x mengekalkan du pada sistem fail yang mengandungi /var, supaya sistem fail bersarang tidak ditambah pada jumlah keseluruhan. -B1 menghapuskan kekaburan unit blok. Jalankan du dengan keistimewaan yang mencukupi dan baca diagnostiknya; menyekat ralat kebenaran tanpa memeriksanya menukar masalah capaian kepada teori storan yang salah. Dapatkan perintah daripada ruang nama lekap yang sama. Bagi penulis dalam bekas, bandingkan paparan hos dengan paparan nsenter yang disengajakan daripada menganggap bahawa rentetan laluan yang serupa menamakan objek yang serupa.

Jurang yang diperhatikan ialah kuantiti diagnostik, bukan fail yang perlu dicari:

same_filesystem_gap = df_used_blocks - du_reachable_allocated_blocks
                    = 196 GiB - 118 GiB
                    = 78 GiB

Persamaan ini adalah anggaran kerana metadata sistem fail, granulariti peruntukan, penulisan serentak, perkongsian salin-semasa-tulis, pemampatan, dan semantik alat tidak membentuk pembahagian yang sempurna. Ia masih berguna: jurang 78 GiB yang stabil adalah terlalu besar untuk diabaikan sebagai pembundaran output. Cari punca yang memperuntukkan blok di luar pohon yang kelihatan dan boleh dicapai sebelum mencari satu lagi laluan fail besar yang biasa.

Pemeriksaan bernilai tertinggi ialah fail terbuka yang pautan direktori terakhirnya telah dialih keluar:

sudo lsof +aL1 /var

# After selecting a candidate from lsof, verify the live descriptor.
sudo readlink /proc/2481/fd/7
sudo stat -Lc 'device=%d inode=%i size=%s blocks=%b block_size=%B' /proc/2481/fd/7

unlink Linux mengalih keluar satu nama. Jika ia adalah pautan terakhir tetapi proses masih membuka fail tersebut, fail dan bloknya kekal sehingga deskriptor rujukan terakhir ditutup. du tidak dapat mencapai inod tersebut melalui pohon direktori; df masih mengira blok yang diperuntukkan. Laluan insiden yang biasa ialah pencatat log (logger) yang terus menulis pada fail selepas pemutaran memadam atau menamakannya semula secara salah.

Jangan anggap nilai SIZE/OFF yang ketara sebagai ramalan penebusgunaan yang tepat bagi setiap fail jarang (sparse file) atau khas. Sahkan bahawa deskriptor itu ialah fail biasa pada peranti sasaran, bahawa kiraan pautannya adalah sifar, proses mana yang memilikinya, sama ada ia masih berkembang, dan sama ada aplikasi mempunyai isyarat buka semula yang didokumentasikan. Korelasikan beberapa deskriptor besar jika satu deskriptor tidak merangkumi sebahagian besar daripada 78 GiB tersebut.

Urutan pemulihan yang diutamakan ialah buka semula khusus aplikasi, muat semula tertib, mula semula tertib atau failover, kemudian campur tangan kecemasan. Tindakan buka semula log yang disokong menutup deskriptor lapuk dan membuka laluan fail semasa tanpa menamatkan keseluruhan hos. Mula semula perkhidmatan yang terkawal juga melepaskannya, tetapi mesti menghormati replika, kesediaan (readiness), dan kerja dalam proses. Menghantar SIGKILL terlebih dahulu membuang laluan pembersihan aplikasi. Mengalih keluar lebih banyak nama tidak memberi sebarang kesan kepada fail yang pautannya telah dipadamkan.

Menulis melalui /proc/PID/fd/FD boleh menebus guna ruang tanpa menghentikan proses, tetapi ia adalah jalan terakhir. Penulis mungkin mengekalkan ofset lama, mencipta lubang jarang (sparse hole) pada penulisan seterusnya, merosakkan format aplikasi, atau gagal dalam varian dalaman. Gunakannya hanya selepas pemilik perkhidmatan mengesahkan deskriptor dan semantik penulisan, trafik dikekang, bukti dipelihara, dan pelan pemulihan wujud. Buku panduan operasi generik (generic runbook) tidak boleh sesekali mengesyorkan pemotongan deskriptor sebagai pembetulan lalai.

Jika lsof tidak dapat menjelaskan jurang tersebut, periksa topologi lekap. Sistem fail yang dilekapkan pada direktori yang tidak kosong menyembunyikan entri direktori di bawahnya manakala bloknya kekal diperuntukkan pada sistem fail induk. findmnt mendedahkan laluan bersarang, paut, dan lekap tindih. Semasa tindakan penyelenggaraan yang diluluskan, ikatan bukan rekursif bagi /var ke sasaran kosong di luar /var boleh mendedahkan paparan induk di bawahnya tanpa menyahlekap lekapan anak pengeluaran:

sudo mkdir -p /mnt/var-underlay
sudo mount --bind /var /mnt/var-underlay
sudo du -x -B1 -s /mnt/var-underlay
sudo umount /mnt/var-underlay

Sahkan pendekatan ini terhadap pohon lekap sebenar terlebih dahulu; penyebaran ruang nama dan dasar platform mungkin mengubah kesannya. Jangan nyahlekap sistem fail pengeluaran yang sibuk semata-mata untuk memeriksanya. Jika fail tersembunyi ditemui, kenal pasti pemilik dan keperluan pengekalan fail tersebut sebelum mengalih atau memadamkannya.

Seterusnya, pisahkan perakaunan ketersediaan daripada jurang ruang yang digunakan. Pada ext4, blok simpanan khas untuk proses berkeistimewaan boleh menyebabkan blok percuma mentah tidak tersedia untuk aplikasi. Periksa dan bukannya mengubah suai:

source=$(findmnt -n -o SOURCE -T /var)
sudo tune2fs -l "$source" | grep -E 'Block count|Reserved block count|Block size'
sudo du --inodes -x -d1 /var | sort -n

Gesaan ini mempunyai 4 GiB antara jumlah keseluruhan dan digunakan tetapi sifar ditunjukkan sebagai tersedia, yang konsisten dengan keadaan beberapa blok percuma tidak tersedia kepada perkhidmatan tanpa keistimewaan. Ini menjelaskan kegagalan penulisan serta-merta, bukan sebab mengapa df menandakan 78 GiB lebih sebagai digunakan berbanding apa yang du boleh capai. Menurunkan simpanan khas semasa insiden boleh mengeluarkan ruang penimbal yang dimaksudkan untuk daemon berkeistimewaan dan meningkatkan risiko pemecahan (fragmentation); ia memerlukan keputusan kapasiti, bukan tune2fs -m 0 secara spontan.

Kehabisan inod ialah satu lagi laluan ENOSPC yang bebas. Di sini df -i menunjukkan 21%, jadi ia bukan pemicu. Jika ia 100%, gunakan du --inodes -x untuk mencari pohon dengan kiraan fail yang tinggi dan alih keluar hanya data yang diliputi oleh dasar pengekalan. Penebusgunaan blok dan penebusgunaan inod adalah objektif yang berasingan.

Perakaunan khusus sistem fail diletakkan pada urutan terakhir. GNU du mendokumenkan bahawa perkongsian salin-semasa-tulis, pemampatan, blok sandaran, dan sistem fail rangkaian boleh menyebabkan anggarannya berbeza daripada penggunaan peranti. Pada Btrfs atau ZFS, periksa subvolum, snapshot, kuota, dan bait eksklusif berbanding dirujuk dengan alatan sistem fail tersebut. Pada storan tindanan, periksa lapisan daripada ruang nama dan masa jalan yang memilikinya. Jangan jalankan alatan ext4 terhadap sumber XFS atau Btrfs.

Jika fail terbuka, data tersembunyi, ralat capaian, pertumbuhan serentak, ketersediaan simpanan khas, dan ciri sistem fail masih tidak menjelaskan bukti tersebut, periksa log kernel dan kesihatan sistem fail. Alat pembaikan bukanlah jalan pintas diagnostik dalam talian: pelihara bukti, gunakan prosedur terdokumentasi sistem fail, dan jadualkan sebarang pemeriksaan yang memerlukan volum yang dinyahlekap.

Tutup insiden dengan set bukti yang sama. Ulangi df -B1, df -i, dan du -x -B1 berkeistimewaan; sahkan bahawa bait yang ditebus guna sepadan dengan peruntukan yang ditutup atau dialih keluar dalam lingkungan overhed yang dijangkakan; sahkan penulisan aplikasi yang baharu; sahkan perkhidmatan kini menulis pada fail dinamakan yang dimaksudkan; dan periksa kependaman, ralat, replika, dan integriti data. Kemudian buat amaran mengenai ruang penimbal blok dan inod, pertumbuhan deleted-open, kegagalan pemutaran log, perubahan topologi lekap, dan pertumbuhan snapshot yang tidak dijangka.

Contoh Jawapan Berkualiti Tinggi

“Perbezaan 78 GiB adalah munasabah kerana df dan du mempunyai skop perakaunan yang berbeza. df memperoleh statistik blok bagi seluruh sistem fail, manakala du menyusuri entri dinamakan yang boleh dicapainya. Saya akan terlebih dahulu membuktikan ini adalah jurang sebenar dengan memetakan /var dengan findmnt, menjalankan kedua-dua alat dalam ruang nama lekap perkhidmatan yang terjejas, menggunakan unit bait, du -x, keistimewaan root, dan sampel yang diambil hampir serentak. Inod hanya 21%, jadi saya akan mengetepikan cabang itu.

Hipotesis pertama saya ialah fail deleted-open. Saya akan menjalankan lsof +aL1 /var, kemudian mengesahkan setiap hasil carian yang besar dari segi PID, deskriptor fail, peranti, inod, pemilik, dan pertumbuhannya. Jika pencatat log masih memegang kira-kira jumlah ruang yang hilang, saya akan menggunakan isyarat buka semula yang disokongnya atau mula semula secara tertib terkawal. Saya akan mengelak daripada mematikan proses atau memotong /proc sehingga pemilik perkhidmatan mengesahkan radius impaknya. Selepas deskriptor ditutup, saya akan memeriksa bahawa df menebus guna julat yang dijangkakan dan bahawa aplikasi menulis pada log dinamakan yang baharu.

Jika itu tidak menjelaskan jurang tersebut, saya akan memeriksa output findmnt untuk direktori yang fail dasarnya disembunyikan oleh lekapan lain, menyemak ralat kebenaran du, dan kemudian menggunakan alat khusus sistem fail untuk snapshot, peruntukan salin-semasa-tulis, kuota, dan metadata. Oleh kerana volum ini adalah ext4, saya akan memeriksa blok simpanan khas. Ia boleh menjelaskan mengapa perkhidmatan mempunyai sifar bait tersedia walaupun jumlah keseluruhan tolak yang digunakan ialah 4 GiB, tetapi ia tidak dapat menjelaskan jurang ruang digunakan sebanyak 78 GiB.

Saya akan menyelesaikan dengan mengulangi pengukuran asal, menguji laluan penulisan yang gagal, memeriksa kesihatan perkhidmatan dan integriti data, serta merekodkan dengan tepat peruntukan mana yang telah dilepaskan. Kerja pencegahan adalah memperbetulkan pemutaran log atau kitaran hayat lekap, memberi amaran pada kedua-dua blok dan inod, serta memantau pertumbuhan unlinked-open sebelum sistem fail mencapai had simpanan kecemasan.”

Kesilapan Lazim

• Memadam fail terbesar yang kelihatan serta-merta → ia mungkin data yang diperlukan dan mungkin tidak menjelaskan

peruntukan yang tidak kelihatan → selaraskan skop pengukuran dan kenal pasti pemilik sebelum menukar data.

• Membandingkan df /var dengan du / → sistem fail bersarang dan punca lekap yang berbeza membatalkan penolakan

→ petakan laluan yang gagal dan gunakan du -x pada sistem fail yang sama.

• Mengabaikan ralat kebenaran du → fail dinamakan yang tidak dapat dicapai menjadikan jumlahnya rendah secara palsu → **jalankan

dengan keistimewaan yang mencukupi dan semak setiap diagnostik.**

• Menjalankan perintah dalam ruang nama lekap yang berbeza → laluan fail yang sama boleh merujuk kepada sistem fail

yang berbeza → kumpulkan kedua-dua ukuran dalam ruang nama proses yang terjejas.

• Memanggil jurang 78 GiB sebagai “blok simpanan khas (reserved blocks)” → simpanan khas ext4 menjejaskan ketersediaan tanpa keistimewaan, manakala

jurang itu membandingkan blok yang digunakan dengan peruntukan yang boleh dicapai → kira setiap perbezaan secara berasingan.

• Menggunakan rm pada fail deleted-open → nama terakhirnya telah pun tiada dan deskriptor hidup

mengekalkan inod diperuntukkan → pastikan proses pemilik menutup atau membuka semula deskriptor dengan selamat.

• Menghantar kill -9 sebagai pembetulan pertama → penamatan mendadak boleh menyebabkan kehilangan kerja dan memintas pembersihan → **utamakan

laluan buka semula, muat semula, mula semula tertib, atau failover yang disokong.**

• Memotong /proc/PID/fd/FD mengikut kebiasaan → ofset yang dikekalkan dan andaian format fail boleh mencipta rasuah data

yang baharu → khaskan pemotongan untuk kecemasan yang diluluskan dengan semantik yang disahkan.

• Nyahlekap lekapan anak yang sibuk untuk mendedahkan fail tersembunyi → perkhidmatan yang bergantung boleh gagal serta-merta →

periksa topologi dan gunakan paparan alternatif yang diluluskan atau tetingkap penyelenggaraan.

• Menganggap penggunaan inod sebagai sebahagian daripada jurang bait → kehabisan inod ialah mekanisme ENOSPC yang berasingan →

periksa df -i dan diagnosis kiraan fail yang tinggi secara bebas.

• Menggunakan perintah ext4 pada setiap sistem fail → semantik snapshot dan peruntukan berbeza merentas XFS,

Btrfs, ZFS, dan lapisan tindanan → kenal pasti FSTYPE dan gunakan alatan yang disokongnya.

• Berhenti selepas df menurun → penulis mungkin masih tidak sihat atau mencatat log ke sasaran yang salah →

sahkan penulisan aplikasi, fail dinamakan, integriti data, dan isyarat keberulangan.

Soalan Susulan dan Maklum Balas

Susulan 1: Bagaimana jika lsof tidak tersedia atau tidak melihat proses tersebut?

Periksa /proc/PID/fd dalam ruang nama PID dan lekap yang sama seperti penulis, cari pautan simbolik (symlinks) yang berakhir dengan (deleted), kemudian sahkan peranti, inod, kiraan pautan, dan pemilikan proses. lsof hos mungkin terlepas proses dalam bekas jika kebenaran, ruang nama PID, atau dasar keselamatan menyembunyikannya. Jangan jadikan pemotongan /proc sebagai langkah automatik seterusnya; keputusan pemulihan kekal khusus untuk perkhidmatan.

Susulan 2: Bagaimana jika sebaliknya du lebih besar daripada df?

Mula-mula periksa sama ada du merentasi ke dalam sistem fail bersarang; du -x menghapuskan punca tersebut. Kemudian periksa semantik argumen pautan keras (hard link), pilihan saiz ketara (apparent-size), pemadaman serentak, dan perakaunan salin-semasa-tulis atau pemampatan. du menganggarkan hierarki direktori yang dipilih, manakala df melaporkan satu sistem fail, jadi arah percanggahan mengubah jenis ralat skop yang munasabah.

Susulan 3: Apakah perubahan pada Btrfs atau ZFS?

Saiz fail yang kelihatan adalah tidak mencukupi kerana snapshot dan perkongsian salin-semasa-tulis boleh mengekalkan blok selepas laluan fail dipadamkan. Gunakan paparan ruang, subvolum atau dataset, snapshot, dan kuota bagi sistem fail itu sendiri; bezakan peruntukan yang dirujuk daripada peruntukan eksklusif; dan padam snapshot hanya di bawah dasar pengekalan yang eksplisit. Penaakulan blok simpanan khas ext4 dan tune2fs tidak boleh diguna pakai di sini.

Susulan 4: Bolehkah kita menetapkan peratusan simpanan khas ext4 kepada sifar untuk pulih serta-merta?

Hanya selepas semakan kapasiti dan kebolehpercayaan. Simpanan khas membolehkan proses berkeistimewaan diteruskan dan boleh mengurangkan pemecahan. Ia mungkin memulihkan ketersediaan tanpa keistimewaan, tetapi ia tidak membuang blok yang digunakan atau menjelaskan peruntukan deleted-open. Tebus guna atau luaskan kapasiti yang diketahui terlebih dahulu, kemudian laraskan simpanan khas mengikut peranan volum dan dasar operasi.

Susulan 5: Bagaimanakah anda menghasilkan semula kelakuan deleted-open dengan selamat?

Gunakan sistem fail pakai buang atau hos ujian: buka fail ujian yang besar dengan satu proses, padamkan pautan laluan failnya semasa deskriptor masih dibuka, bandingkan df dan du, perhatikan ia dengan lsof +L1, kemudian tutup deskriptor dan sahkan bahawa blok tersebut kembali. Jangan reka eksperimen ini pada volum pengeluaran atau menggunakan semula deskriptor perkhidmatan sebenar.

Susulan 6: Apakah yang patut diukur oleh amaran jangka panjang?

Beri amaran mengenai masa-hingga-kehabisan (time-to-exhaustion) dan ruang penimbal minimum untuk kedua-dua blok dan inod, dibahagikan mengikut sistem fail dan ruang nama. Tambah tolok (gauge) atau inventori berkala untuk fail biasa deleted-open, kegagalan pemutaran log, pertumbuhan snapshot, dan perubahan topologi lekap. Amaran tersebut harus dipautkan ke buku panduan operasi yang bermula dengan penyelarasan skop dan memerlukan kelulusan pemilik sebelum pemulihan pemusnahan dijalankan.