Wawancara Linux: Mengapa df dan du Menampilkan Penggunaan Disk yang Berbeda?

Perintah dan Konteks yang Berlaku

Pada pukul 02:00, sebuah aplikasi mulai menerima ENOSPC saat menulis di bawah /var. Host 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 dibulatkan adalah total 200 GiB, 196 GiB digunakan oleh df, dan 118 GiB dapat dijangkau melalui du, menyisakan selisih ruang terpakai sebesar 78 GiB. Output inode mengesampingkan habisnya inode sebagai penyebab langsung. Layanan ini tidak memiliki hak istimewa (unprivileged), host tidak dapat di-reboot, dan tidak ada berkas yang boleh dihapus sampai pemilik dan tujuannya diketahui.

Ini adalah pertanyaan pemecahan masalah produksi (production troubleshooting) Linux. Jawaban terkuat tidak dimulai dengan menghapus jalur berkas terbesar. Jawaban tersebut pertama-tama membuktikan bahwa kedua alat mengamati sistem berkas, namespace, waktu, unit, dan cakupan akses yang sama; kemudian menjelaskan alokasi mana yang dapat ada di luar hierarki direktori yang terlihat dan memilih tindakan pemulihan yang dampak kerusakannya (blast radius) dipahami.

Apa yang Dievaluasi Pewawancara

Sinyal pertama adalah model pengukuran yang benar. df meminta statistik blok keseluruhan dari sistem berkas yang terpasang (mounted). du menelusuri berkas dan direktori bernama serta memperkirakan blok yang direpresentasikan oleh entri yang dapat dijangkaunya. Keduanya mengukur set yang terkait tetapi berbeda. Alokasi besar yang ditahan oleh berkas yang telah di-unlink atau tersembunyi di bawah direktori yang ditimpa pemasangan (over-mounted) tetap berada dalam total sistem berkas meskipun penelusuran saat ini tidak dapat menamainya.

Sinyal kedua adalah kontrol cakupan (scope control). Membandingkan df /var dengan du /var tanpa batasan, menjalankan satu perintah di dalam kontainer, mengabaikan kesalahan izin (permission errors), atau membandingkan sampel yang diambil selama proses penulisan yang cepat dapat memicu diskrepansi palsu. Seorang kandidat harus menyelaraskan target mount, mount namespace, batasan sistem berkas, unit byte, hak istimewa, dan jendela observasi sebelum menetapkan penyebabnya.

Sinyal ketiga adalah respons insiden yang aman. lsof +aL1 /var dapat mengidentifikasi berkas terbuka dengan jumlah tautan (link count) di bawah satu pada sistem berkas tersebut, tetapi output-nya adalah bukti, bukan izin untuk mematikan proses atau memotong (truncate) deskriptor. Jawaban yang kuat mengidentifikasi pemilik layanan, mengonfirmasi deskriptor berkas dan perangkat, memprioritaskan pembukaan kembali log yang didukung aplikasi atau restart yang mulus (graceful restart), serta memverifikasi reklamasi disk dan kesehatan aplikasi.

Sinyal keempat adalah memisahkan penyebab yang terlihat serupa. Blok cadangan ext4 mengurangi ruang yang tersedia untuk proses penulisan tanpa hak istimewa dan dapat membuat Size - Used melebihi Avail; hal tersebut tidak menjelaskan mengapa 78 GiB dihitung sebagai terpakai oleh df tetapi tidak ada dalam penelusuran du pada sistem berkas yang sama. Habisnya inode juga dapat mengembalikan ENOSPC, tetapi penggunaan inode sebesar 21% dalam skenario menolak kemungkinan tersebut. Snapshot copy-on-write, kompresi, dan kuota memerlukan alat khusus sistem berkas, bukan perintah ext4 yang disalin secara membabi buta.

Sinyal terakhir adalah penyelesaian menyeluruh (closure). Jawaban harus menetapkan kumpulan bukti sebelum dan sesudah, menjelaskan rentang byte yang direklamasi, mengonfirmasi bahwa penulis membuka kembali jalur berkas yang dimaksud, memeriksa pertumbuhan berulang dari berkas yang dihapus tetapi masih terbuka, dan meningkatkan rotasi log atau pemantauan perubahan mount. Persentase yang lebih rendah di df saja tidak membuktikan bahwa aplikasi sehat atau data berhasil dipertahankan.

Pertanyaan yang Perlu Diklarifikasi Sebelum Menjawab

• Apakah kedua perintah berjalan di mount namespace yang sama? Jika satu berjalan di host dan yang lain di namespace kontainer atau layanan, /var dapat mengarah ke mount yang berbeda. Investigasi harus masuk ke namespace proses yang terdampak atau secara sengaja tetap berada di host.
• Jalur mana yang sebenarnya gagal dan sistem berkas mana yang memuatnya? findmnt -T memetakan jalur arbitrer ke mount-nya. Nested mount atau bind mount mengubah apa yang harus dibandingkan antara df dan du.
• Apakah sampel diambil bersamaan dengan unit dan hak istimewa yang sama? Log yang tumbuh cepat dapat berubah di antara eksekusi perintah, pembulatan human-readable menyembunyikan perbedaan kecil, dan direktori yang tidak dapat dibaca membuat du tanpa hak istimewa menghitung lebih sedikit dari yang sebenarnya.
• Lapisan sistem berkas dan penyimpanan apa yang terlibat? ext4, XFS, Btrfs, ZFS, sistem berkas overlay, snapshot LVM, dan snapshot volume cloud memiliki kontrol akuntansi dan pemulihan yang berbeda.
• Apakah kekurangannya ada pada blok data, inode, atau kuota? df -i, alat kuota, dan galat aplikasi membedakan cabangnya. Menghapus satu berkas besar tidak menyelesaikan masalah habisnya inode, dan blok global yang bebas tidak menimpa kuota pengguna atau proyek.
• Tindakan pemulihan mana yang diizinkan secara operasional? Sinyal buka kembali log (log-reopen), graceful restart, failover, atau jendela pemeliharaan singkat memiliki risiko ketersediaan yang berbeda. Pemotongan deskriptor darurat memerlukan kepemilikan yang jelas dan perencanaan rollback.
• Berapa banyak kapasitas luang yang harus dipulihkan, dan kapan batas waktunya? Target menentukan apakah akan menahan penulisan, memperluas volume, mengalihkan lalu lintas (failover), atau mereklamasi alokasi yang diketahui terlebih dahulu. Hal ini tidak membenarkan penghapusan data yang tidak diketahui.

Kerangka Jawaban 30 Detik

“Saya pertama-tama akan membekukan tindakan destruktif dan membandingkan jalur, sistem berkas, mount namespace, waktu, hak istimewa, dan unit byte yang sama menggunakan findmnt, df -B1, dan sudo du -x -B1. Dengan penggunaan inode sebesar 21%, saya akan mengukur selisih blok sebesar 78 GiB dan memeriksa lsof +aL1 /var untuk mencari berkas ter-unlink yang masih dibuka oleh proses. Jika ada yang menjelaskan selisih tersebut, saya akan memverifikasi PID, deskriptor, perangkat, dan pemilik layanannya, lalu menggunakan jalur log-reopen aplikasi atau graceful restart dan mengonfirmasi ruang disk kembali. Jika tidak, saya akan memeriksa direktori yang tertimpa mount (over-mounted), kesalahan izin, dan metadata atau snapshot spesifik sistem berkas. Blok cadangan ext4 menjelaskan ketiadaan ruang bagi unprivileged service, bukan selisih ruang terpakai 78 GiB. Saya akan menutupnya dengan mengulangi pengukuran dan memeriksa penulisan aplikasi, log, dan potensi kejadian berulang.”

Pembahasan Mendalam Langkah-demi-Langkah

Mulailah dengan membuat perbandingannya dapat direproduksi. Ambil jalur yang gagal, namespace saat ini, sumber mount, jenis sistem berkas, statistik blok, statistik inode, dan total du dalam waktu yang berdekatan:

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

-x menjaga du tetap berada pada sistem berkas yang memuat /var, sehingga sistem berkas bersarang (nested) tidak ditambahkan ke total. -B1 menghilangkan ambiguitas unit blok. Jalankan du dengan hak istimewa yang cukup dan baca diagnostiknya; menyembunyikan kesalahan izin tanpa memeriksanya mengubah masalah akses menjadi teori penyimpanan yang salah. Ambil perintah dari mount namespace yang sama. Untuk proses penulisan di dalam kontainer, bandingkan tampilan host dengan tampilan nsenter yang disengaja alih-alih mengasumsikan bahwa string jalur yang identik merujuk ke objek yang identik.

Selisih yang diamati adalah kuantitas diagnostik, bukan berkas yang harus dicari:

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

Persamaan ini bersifat perkiraan karena metadata sistem berkas, granularitas alokasi, penulisan bersamaan, pembagian copy-on-write, kompresi, dan semantik alat tidak membentuk partisi yang sempurna. Namun ini tetap berguna: selisih 78 GiB yang stabil terlalu besar untuk diabaikan sebagai pembulatan output. Cari penyebab yang mengalokasikan blok di luar hierarki yang terlihat dan dapat dijangkau sebelum mencari jalur berkas besar biasa lainnya.

Pemeriksaan bernilai tertinggi adalah berkas terbuka yang tautan direktori terakhirnya telah dihapus:

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

Linux unlink menghapus nama. Jika itu adalah tautan terakhir tetapi proses masih membuka berkas tersebut, berkas dan bloknya tetap ada sampai deskriptor terakhir yang merujuknya ditutup. du tidak dapat mencapai inode tersebut melalui hierarki direktori; df tetap menghitung blok yang dialokasikannya. Jalur insiden yang umum adalah pencatat log (logger) yang terus menulis ke berkas setelah proses rotasi menghapus atau mengganti namanya secara tidak benar.

Jangan memperlakukan nilai SIZE/OFF yang terlihat sebagai perkiraan reklamasi yang pasti untuk setiap berkas renggang (sparse file) atau berkas khusus. Konfirmasikan bahwa deskriptor tersebut adalah berkas reguler pada perangkat target, jumlah tautannya nol, proses mana yang memilikinya, apakah berkas masih bertambah besar, dan apakah aplikasi memiliki sinyal buka kembali yang terdokumentasi. Korelasikan beberapa deskriptor besar jika satu deskriptor tidak mencakup sebagian besar dari 78 GiB tersebut.

Urutan pemulihan yang lebih disukai adalah pembukaan kembali khusus aplikasi, pemuatan ulang yang mulus (graceful reload), graceful restart atau failover, lalu intervensi darurat. Tindakan buka kembali log yang didukung akan menutup deskriptor usang dan membuka jalur berkas saat ini tanpa menghentikan seluruh host. Restart layanan yang terkontrol juga melepaskannya, tetapi harus menghormati replika, kesiapan (readiness), dan pekerjaan yang sedang berjalan (in-flight work). Mengirim SIGKILL terlebih dahulu akan mengabaikan jalur pembersihan aplikasi. Menghapus lebih banyak nama tidak berpengaruh apa pun pada berkas yang sudah di-unlink.

Menulis melalui /proc/PID/fd/FD dapat mereklamasi ruang tanpa menghentikan proses, tetapi ini adalah upaya terakhir. Penulis dapat mempertahankan offset lama, membuat lubang renggang (sparse hole) pada penulisan berikutnya, merusak format aplikasi, atau menggagalkan invarian internal. Gunakan hanya setelah pemilik layanan mengonfirmasi deskriptor dan semantik penulisan, lalu lintas terkendali, bukti dipertahankan, dan rencana pemulihan tersedia. Runbook umum tidak boleh mengiklankan pemotongan deskriptor sebagai perbaikan default.

Jika lsof tidak dapat menjelaskan selisihnya, periksa topologi mount. Sistem berkas yang dipasang di atas direktori yang tidak kosong menyembunyikan entri direktori di bawahnya sementara bloknya tetap dialokasikan pada sistem berkas induk. findmnt mengungkap jalur yang bersarang, di-bind, dan ditimpa (over-mounted). Selama tindakan pemeliharaan yang disetujui, bind non-rekursif dari /var ke target kosong di luar /var dapat mengekspos tampilan induk di bawahnya tanpa melepas (unmount) mount anak produksi:

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

Validasi pendekatan ini terhadap hierarki mount yang sebenarnya terlebih dahulu; propagasi namespace dan kebijakan platform dapat mengubah efeknya. Jangan melepaskan sistem berkas produksi yang sedang sibuk hanya untuk memeriksanya. Jika berkas tersembunyi ditemukan, identifikasi pemilik dan persyaratan retensinya sebelum memindahkan atau menghapusnya.

Selanjutnya pisahkan akuntansi ketersediaan dari selisih ruang terpakai. Pada ext4, blok cadangan proses berhak istimewa dapat membuat blok bebas mentah tidak tersedia untuk aplikasi. Lakukan inspeksi alih-alih memodifikasi:

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

Skenario memiliki 4 GiB antara total dan terpakai tetapi nol ditampilkan sebagai tersedia, yang konsisten dengan beberapa blok bebas yang tidak tersedia untuk layanan tanpa hak istimewa. Hal itu menjelaskan kegagalan penulisan langsung, bukan mengapa df menandai 78 GiB lebih banyak sebagai terpakai daripada yang dapat dijangkau oleh du. Menurunkan cadangan selama insiden dapat menghilangkan ruang yang ditujukan untuk daemon berhak istimewa dan meningkatkan risiko fragmentasi; hal ini memerlukan keputusan kapasitas, bukan tindakan refleks tune2fs -m 0.

Habisnya inode adalah jalur ENOSPC independen lainnya. Di sini df -i menunjukkan 21%, jadi ini bukan pemicunya. Jika 100%, gunakan du --inodes -x untuk menemukan hierarki dengan jumlah berkas tinggi dan hapus hanya data yang dicakup oleh kebijakan retensi. Reklamasi blok dan reklamasi inode adalah tujuan yang terpisah.

Akuntansi khusus sistem berkas dilakukan paling akhir. GNU du mendokumentasikan bahwa pembagian copy-on-write, kompresi, blok cadangan, dan sistem berkas jaringan dapat membuat perkiraannya menyimpang dari konsumsi perangkat. Pada Btrfs atau ZFS, periksa subvolume, snapshot, kuota, dan byte eksklusif versus yang direferensikan dengan alat sistem berkas tersebut. Pada penyimpanan overlay, periksa lapisan dari namespace dan runtime yang memilikinya. Jangan jalankan alat ext4 terhadap sumber XFS atau Btrfs.

Jika berkas terbuka, data tersembunyi, kesalahan akses, pertumbuhan bersamaan, ketersediaan cadangan, dan fitur sistem berkas masih belum menjelaskan buktinya, periksa log kernel dan kesehatan sistem berkas. Alat perbaikan bukanlah jalan pintas diagnostik online: pertahankan bukti, gunakan prosedur terdokumentasi dari sistem berkas, dan jadwalkan pemeriksaan apa pun yang memerlukan volume yang tidak terpasang (unmounted).

Tutup insiden dengan kumpulan bukti yang sama. Ulangi df -B1, df -i, dan du -x -B1 berhak istimewa; konfirmasikan bahwa byte yang direklamasi cocok dengan alokasi yang ditutup atau dihapus dalam batas overhead yang diharapkan; verifikasi penulisan aplikasi baru; konfirmasikan bahwa layanan sekarang menulis ke berkas bernama yang dimaksud; dan periksa latensi, kesalahan, replika, serta integritas data. Kemudian buat peringatan (alert) pada kapasitas luang blok dan inode, pertumbuhan deleted-open, kegagalan rotasi log, perubahan topologi mount, dan pertumbuhan snapshot yang tidak terduga.

Contoh Jawaban Berkualitas Tinggi

“Perbedaan 78 GiB ini masuk akal karena df dan du memiliki cakupan akuntansi yang berbeda. df mendapatkan statistik blok di seluruh sistem berkas, sementara du menelusuri entri bernama yang dapat dijangkaunya. Pertama-tama saya akan membuktikan bahwa ini adalah selisih nyata dengan memetakan /var dengan findmnt, menjalankan kedua alat di mount namespace layanan yang terdampak, menggunakan unit byte, du -x, hak istimewa root, dan pengambilan sampel yang hampir bersamaan. Penggunaan inode hanya 21%, jadi saya akan mengesampingkan cabang tersebut.

Hipotesis pertama saya adalah berkas yang dihapus tetapi masih terbuka (deleted-open files). Saya akan menjalankan lsof +aL1 /var, lalu memverifikasi PID, deskriptor berkas, perangkat, inode, pemilik, dan pertumbuhan dari setiap hasil yang besar. Jika sebuah pencatat log masih menahan sekitar ruang yang hilang tersebut, saya akan menggunakan sinyal buka kembali yang didukung atau graceful restart yang terkontrol. Saya akan menghindari mematikan proses atau memotong /proc sampai pemilik layanan mengonfirmasi dampak kerusakannya. Setelah deskriptor ditutup, saya akan memeriksa bahwa df mereklamasi rentang yang diharapkan dan aplikasi menulis ke log bernama yang baru.

Jika hal itu tidak menjelaskan selisihnya, saya akan memeriksa output findmnt untuk mencari direktori yang berkas dasarnya tersembunyi oleh mount lain, meninjau kesalahan izin du, lalu menggunakan alat khusus sistem berkas untuk snapshot, alokasi copy-on-write, kuota, dan metadata. Karena volume ini adalah ext4, saya akan memeriksa blok cadangan. Blok tersebut dapat menjelaskan mengapa layanan memiliki nol byte yang tersedia meskipun total dikurangi terpakai adalah 4 GiB, tetapi tidak dapat menjelaskan selisih ruang terpakai 78 GiB.

Saya akan menyelesaikan dengan mengulangi pengukuran awal, menguji jalur penulisan yang gagal, memeriksa kesehatan layanan dan integritas data, serta mencatat dengan tepat alokasi mana yang dilepaskan. Pekerjaan pencegahannya adalah memperbaiki rotasi log atau siklus hidup mount, membuat peringatan untuk blok dan inode, serta memantau pertumbuhan berkas yang di-unlink tetapi masih terbuka sebelum sistem berkas mencapai cadangan darurat.”

Kesalahan Umum

• Menghapus berkas terlihat terbesar secara langsung → berkas tersebut mungkin data penting dan mungkin tidak menjelaskan alokasi yang tidak terlihat → selaraskan cakupan pengukuran dan identifikasi pemiliknya sebelum mengubah data.
• Membandingkan df /var dengan du / → sistem berkas bersarang dan root yang berbeda membuat pengurangan tidak valid → petakan jalur yang gagal dan gunakan du -x pada sistem berkas yang sama.
• Mengabaikan kesalahan izin du → berkas bernama yang tidak dapat dijangkau membuat totalnya menjadi rendah secara artifisial → jalankan dengan hak istimewa yang memadai dan tinjau setiap diagnostik.
• Menjalankan perintah di mount namespace yang berbeda → jalur yang sama dapat mengarah ke sistem berkas yang berbeda → kumpulkan kedua pengukuran di namespace proses yang terdampak.
• Menyebut selisih 78 GiB sebagai “blok cadangan” → cadangan ext4 memengaruhi ketersediaan untuk unprivileged service, sedangkan selisih tersebut membandingkan blok terpakai dengan alokasi yang dapat dijangkau → hitung setiap perbedaan secara terpisah.
• Menggunakan rm pada berkas yang sudah dihapus tetapi masih terbuka → nama akhirnya sudah hilang dan deskriptor yang aktif menjaga inode tetap dialokasikan → buat proses pemilik menutup atau membuka kembali deskriptor secara aman.
• Mengirim kill -9 sebagai perbaikan pertama → penghentian tiba-tiba dapat menghilangkan pekerjaan dan melewati proses pembersihan → prioritaskan jalur buka kembali yang didukung, muat ulang, graceful restart, atau failover.
• Memotong /proc/PID/fd/FD karena kebiasaan → offset yang tertahan dan asumsi format berkas dapat menciptakan kerusakan baru → khususkan pemotongan hanya untuk keadaan darurat yang disetujui dengan semantik yang terverifikasi.
• Melepas mount anak yang sibuk untuk mengungkap berkas tersembunyi → layanan yang bergantung dapat langsung gagal → periksa topologi dan gunakan tampilan alternatif atau jendela pemeliharaan yang disetujui.
• Memperlakukan penggunaan inode sebagai bagian dari selisih byte → habisnya inode adalah mekanisme ENOSPC yang terpisah → periksa df -i dan diagnosis jumlah berkas yang tinggi secara independen.
• Menerapkan perintah ext4 ke setiap sistem berkas → semantik snapshot dan alokasi berbeda pada lapisan XFS, Btrfs, ZFS, dan overlay → identifikasi FSTYPE dan gunakan alat yang didukungnya.
• Berhenti setelah df turun → proses penulisan mungkin masih tidak sehat atau mencatat ke target yang salah → verifikasi penulisan aplikasi, berkas bernama, integritas data, dan sinyal kekambuhan.

Pertanyaan Lanjutan dan Tanggapan

Pertanyaan lanjutan 1: Bagaimana jika lsof tidak tersedia atau tidak melihat prosesnya?

Periksa /proc/PID/fd di PID dan mount namespace yang sama dengan penulis, cari symlink yang berakhiran (deleted), lalu verifikasi perangkat, inode, jumlah tautan, dan kepemilikan proses. lsof host mungkin melewatkan proses dalam kontainer jika izin, PID namespace, atau kebijakan keamanan menyembunyikannya. Jangan jadikan pemotongan /proc sebagai langkah otomatis berikutnya; keputusan pemulihan tetap spesifik untuk setiap layanan.

Pertanyaan lanjutan 2: Bagaimana jika du justru lebih besar daripada df?

Pertama-tama periksa apakah du merambah ke sistem berkas bersarang; du -x menghilangkan sumber masalah tersebut. Kemudian periksa semantik argumen hard link, opsi apparent-size, penghapusan bersamaan, dan akuntansi copy-on-write atau kompresi. du memperkirakan hierarki direktori yang dipilih, sementara df melaporkan satu sistem berkas, sehingga arah diskrepansi mengubah jenis kesalahan cakupan yang masuk akal.

Pertanyaan lanjutan 3: Apa yang berubah pada Btrfs atau ZFS?

Ukuran berkas yang terlihat tidak cukup karena snapshot dan pembagian copy-on-write dapat mempertahankan blok setelah jalur berkas dihapus. Gunakan tampilan ruang, subvolume atau dataset, snapshot, dan kuota milik sistem berkas itu sendiri; bedakan alokasi yang direferensikan dari yang eksklusif; dan hapus snapshot hanya di bawah kebijakan retensi yang eksplisit. Penalaran blok cadangan ext4 dan tune2fs tidak berlaku di sini.

Pertanyaan lanjutan 4: Bisakah kita menyetel persentase cadangan ext4 ke nol untuk memulihkannya secara langsung?

Hanya setelah peninjauan kapasitas dan keandalan. Cadangan memungkinkan proses berhak istimewa untuk terus berjalan dan dapat mengurangi fragmentasi. Hal ini dapat memulihkan ketersediaan bagi proses tanpa hak istimewa, tetapi tidak menghapus blok yang digunakan atau menjelaskan alokasi berkas yang dihapus tetapi masih terbuka. Reklamasi atau perluas kapasitas yang diketahui terlebih dahulu, lalu sesuaikan cadangan menurut peran volume dan kebijakan operasional.

Pertanyaan lanjutan 5: Bagaimana Anda mereproduksi perilaku berkas yang dihapus tetapi masih terbuka dengan aman?

Gunakan sistem berkas sekali pakai atau host pengujian: buka berkas uji besar dengan sebuah proses, unlink jalurnya sementara deskriptor tetap terbuka, bandingkan df dan du, amati dengan lsof +L1, lalu tutup deskriptor dan konfirmasikan blok kembali bebas. Jangan membuat eksperimen pada volume produksi atau menggunakan kembali deskriptor layanan nyata.

Pertanyaan lanjutan 6: Apa yang harus diukur oleh sistem peringatan jangka panjang?

Beri peringatan tentang waktu menuju habisnya kapasitas (time-to-exhaustion) dan kapasitas luang minimum untuk blok dan inode, yang disegmentasikan berdasarkan sistem berkas dan namespace. Tambahkan pengukur (gauge) atau inventaris berkala untuk berkas reguler yang dihapus tetapi masih terbuka, kegagalan rotasi log, pertumbuhan snapshot, dan perubahan topologi mount. Peringatan harus menautkan ke runbook yang dimulai dengan penyelarasan cakupan dan memerlukan persetujuan pemilik sebelum pemulihan destruktif dilakukan.