อาการสร้างไฟล์ใหม่ไม่ได้มักทำให้เริ่มจากดูว่าดิสก์เต็มหรือยัง แต่คำว่าพื้นที่ยังเหลือบนหน้าจอหนึ่งอาจไม่ตรงกับพื้นที่ที่ process กำลังเขียน และบางข้อจำกัดก็ไม่ได้คิดเป็นจำนวน byte เพียงอย่างเดียว
เครื่องหนึ่งอาจมีหลาย filesystem ทั้ง root data volume และพื้นที่ของ container การลบไฟล์จากที่หนึ่งจึงไม่จำเป็นต้องเพิ่มพื้นที่ให้อีกที่ หากยังไม่ระบุปลายทางจริง การคืนพื้นที่แบบรีบทำก็อาจลบข้อมูลที่ไม่เกี่ยวกับเหตุขัดข้องเลย
ก่อนเลือกไฟล์ที่จะจัดการ ควรแยกว่าอะไรเป็นทรัพยากรที่หมดครับ ทั้งพื้นที่ข้อมูล inode โควตา และไฟล์ที่ยังมี process ถือใช้อยู่
เก็บ path ที่โปรแกรมพยายามสร้างไฟล์ พร้อมข้อความหรือรหัสข้อผิดพลาดก่อน ถ้าเป็น permission denied การเพิ่มพื้นที่ว่างก็ไม่ได้แก้สิทธิ์ ส่วนกรณี read-only filesystem ก็ต้องตามเหตุที่ mount อยู่ในสภาพนั้น ไม่เหมารวมเป็นดิสก์เต็มทั้งหมด
จากนั้นดูว่า path อยู่บน filesystem ใด การเรียก df โดยระบุ path ช่วยให้ผลผูกกับพื้นที่ที่เกี่ยวข้องมากกว่าดูเฉพาะบรรทัด root ของเครื่อง โดยต้องตรวจในบริบทที่ process เห็น path ด้วย
หากแอปรันใน container ชื่อ directory ข้างในอาจเป็น volume หรือชั้นเขียนอีกตำแหน่งบน host ต้องตาม mapping ก่อนเทียบตัวเลข ไม่ใช้พื้นที่ว่างของโฟลเดอร์โปรเจกต์บนเครื่องพัฒนาไปรับรองที่เก็บจริงของ container
ตัวอย่างคำสั่งอ่านข้อมูลต่อไปนี้ใช้ path สมมติ ต้องเปลี่ยนให้ตรงกับระบบที่มีสิทธิ์ตรวจ ไม่ใช่ผลจากเครื่องของผู้ใช้หรือข้อมูลว่าพื้นที่ใดเต็มแล้ว
df -h /path/to/data
df -i /path/to/data
df แบบที่ดูพื้นที่ block ช่วยบอกการใช้พื้นที่ข้อมูล ส่วนตัวเลือก -i ของ GNU df แสดงข้อมูล inode แทน ใน filesystem ที่มีขอบเขตของ inode เราอาจสร้างไฟล์จำนวนมากจนติดข้อจำกัดนี้ได้แม้พื้นที่ข้อมูลยังเหลือ
งานที่มีไฟล์เล็กจำนวนมาก เช่น ชิ้น cache หรือผลแตกไฟล์ชั่วคราว จึงมีรูปแบบใช้ทรัพยากรต่างจากไฟล์ใหญ่ไม่กี่ชิ้น การลบไฟล์ใหญ่หนึ่งไฟล์อาจช่วยเรื่อง byte มาก แต่ไม่ตรงกับปัญหาจำนวน inode ที่ใช้ไปกับไฟล์เล็กจำนวนมาก
อย่างไรก็ตาม filesystem แต่ละชนิดจัดการ inode กับ metadata ต่างกัน ไม่ควรจำจำนวนไฟล์สูงสุดค่าหนึ่งแล้วใช้กับทุกดิสก์ ต้องอ่านชนิด filesystem และเงื่อนไขที่เครื่องมือรายงานด้วย การเห็น percentage สูงเป็นจุดให้ตาม ไม่ใช่ผลพิสูจน์ว่าฮาร์ดแวร์เสีย
โควตาของผู้ใช้หรือขอบเขตที่ระบบกำหนดก็เป็นอีกข้อจำกัดหนึ่ง Linux มี error อย่าง EDQUOT สำหรับบางกรณีที่ quota ของ block หรือ inode หมด แม้ทั้ง filesystem จะยังเหลืออยู่ การตรวจในบัญชีผู้ดูแลที่มีสิทธิ์ต่างกันอาจให้ภาพไม่เหมือน process ที่เขียนจริง
df รายงานสถานะของ filesystem ส่วน du เดินตามไฟล์และ directory ที่อ่านได้เพื่อประมาณการใช้พื้นที่ตามตัวเลือกที่กำหนด ถ้าจุดเริ่มต้น สิทธิ์ หรือขอบเขตการข้าม mount ต่างกัน ตัวเลขก็ไม่ได้เป็นยอดเดียวกันตั้งแต่ต้น
การไล่ du ทั้ง root อาจข้ามเข้า filesystem ที่แยกอยู่และรวมพื้นที่อีกก้อนมาด้วย GNU du มีตัวเลือกจำกัดให้อยู่ใน filesystem เดียวเมื่อเหมาะกับคำถาม แต่ต้องเลือกจากสิ่งที่ต้องตรวจ ไม่ใช้ตัวเลือกหนึ่งโดยไม่รู้ว่ามันตัดส่วนใดออกไป
ขนาดที่โปรแกรมเห็นในฐานะความยาวไฟล์กับพื้นที่ที่ filesystem จัดสรรก็อาจต่างกัน เช่น sparse file จึงต้องระบุด้วยว่ากำลังเทียบ apparent size หรือพื้นที่ใช้จริง ไม่เห็นตัวเลขคนละแบบแล้วสรุปว่ามีข้อมูลหายหรือเครื่องมือโกหก
นอกจากนี้ du ที่ไม่มีสิทธิ์อ่านบาง directory ย่อมไม่ให้ภาพครบเหมือนการรวมทุกไฟล์ ควรอ่าน error ระหว่างเดินด้วย ไม่ทิ้งข้อความนั้นแล้วใช้ยอดท้ายสุดเป็นหลักฐานว่ามีพื้นที่ใช้เพียงเท่านี้แน่นอน
บน Linux การ unlink เป็นการนำชื่ออ้างอิงออกตามกติกาของ filesystem หากเป็น link สุดท้ายแต่ยังมี process เปิดไฟล์อยู่ ตัวไฟล์ยังอยู่จน file descriptor ที่เกี่ยวข้องถูกปิดครบ พื้นที่จึงอาจยังไม่กลับมาให้ใช้ทันที
กรณีนี้อธิบายได้ว่าทำไมไฟล์ไม่อยู่ใน directory ที่เราลองไล่ดูแล้ว แต่พื้นที่ที่ df รายงานยังไม่ลด การสั่งลบชื่อเดิมซ้ำไม่ได้ปิด descriptor ของ process ที่ถืออยู่ และอาจไม่มีไฟล์ชื่อนั้นให้จัดการอีกแล้ว
ต้องหาว่า process ใดเปิดไฟล์นั้นไว้และควรให้มันปิดหรือเปิดไฟล์ใหม่ตามวิธีที่บริการรองรับ การ restart อาจกระทบคำขอหรืองานที่ทำอยู่ จึงควรประเมินหน้าที่ของ process กับขั้นหยุดให้ชัดก่อน ไม่ยุติทุกตัวที่เห็นชื่อไฟล์คล้ายกัน
ไม่ควรแก้ด้วยการเขียนทับผ่าน descriptor หรือ truncate ข้อมูลที่ยังไม่รู้บทบาทเพียงเพื่อให้ยอดว่างเพิ่ม เพราะไฟล์นั้นอาจเป็นข้อมูลหลักที่โปรแกรมกำลังใช้ การเข้าใจว่าพื้นที่ค้างเพราะใครช่วยให้เลือกวิธีคืนพื้นที่ตามเจ้าของงานได้ตรงกว่า
เมื่อระบุได้ว่าติด block inode หรือ quota ค่อยเลือกข้อมูลที่มีวงจรล้างชัดเจน เช่น cache ที่สร้างใหม่ได้ตามนโยบายของแอป ไม่ใช้ชื่อ directory ว่า temp เป็นหลักฐานว่าทุกอย่างข้างในทิ้งได้โดยไม่มีผล
ไฟล์ภายในฐานข้อมูลหรือ runtime ควรจัดการผ่านเครื่องมือและขั้นตอนของระบบนั้น ไม่ลบชิ้นที่ดูใหญ่จากด้านนอกโดยไม่รู้ความสัมพันธ์กับไฟล์อื่น การได้พื้นที่กลับเร็วไม่คุ้มกับการทำข้อมูลหลักเสียแล้วต้องกู้ภายหลัง
หลังเปลี่ยนควรตรวจ path และ metric เดิม พร้อมดูว่า process เขียนทดสอบในสภาพแวดล้อมที่เหมาะสมได้จริงหรือไม่ ถ้าปริมาณยังเพิ่มเร็ว ต้องตามแหล่งสร้างและอายุข้อมูลต่อ ไม่จบที่ลบได้รอบหนึ่งโดยไม่รู้ว่าจะกลับมาติดเมื่อใด
คำว่าดิสก์ยังว่างตอบเพียงส่วนหนึ่งของการสร้างไฟล์ เราต้องรู้ filesystem ของ path ขอบเขต inode quota และอายุของไฟล์ที่ยังเปิดอยู่ด้วย เมื่อแยกหลักฐานแต่ละด้านได้ การคืนพื้นที่จะผูกกับต้นเหตุและเจ้าของข้อมูล ลดการลบผิดจุด และทำให้ติดตามได้ว่าทรัพยากรที่เคยขาดกลับมาพอจริงหรือยัง