ดิสก์เต็ม du บอกแตกต่างกัน วิธีการตรวจสอบต่อไป?

ฉันมีดิสก์ SCSI ในเซิร์ฟเวอร์ (ฮาร์ดแวร์ Raid 1), 32G, ไฟล์นามสกุล ext3 dfบอกฉันว่าดิสก์เต็ม 100% หากฉันลบ 1G จะแสดงอย่างถูกต้อง

อย่างไรก็ตามถ้าฉันเรียกใช้du -h -x /แล้วduบอกฉันว่าใช้เพียง 12G (ฉันใช้-xเพราะเมานท์ Samba บางตัว)

ดังนั้นคำถามของฉันไม่เกี่ยวกับความแตกต่างที่ละเอียดอ่อนระหว่างคำสั่ง du และ df แต่เกี่ยวกับวิธีที่ฉันจะค้นหาว่าอะไรทำให้เกิดความแตกต่างอย่างมากนี้

ฉันรีบูทเครื่องเพื่อหา fsck ที่ผิดพลาด ฉันควรวิ่งbadblocksไหม lsofแสดงให้ฉันเห็นว่าไม่มีไฟล์ที่ถูกลบที่เปิดlost+foundอยู่ว่างเปล่าและไม่มีคำเตือนคำเตือน / ผิดพลาด / ล้มเหลวในไฟล์ข้อความ

อย่าลังเลที่จะสอบถามรายละเอียดเพิ่มเติมเกี่ยวกับการตั้งค่า

ตรวจสอบไฟล์ที่อยู่ใต้จุดเมานท์ บ่อยครั้งถ้าคุณติดตั้งไดเรกทอรี (พูดถึง sambafs) ลงในระบบไฟล์ที่มีไฟล์หรือไดเรกทอรีอยู่แล้วคุณจะสูญเสียความสามารถในการดูไฟล์เหล่านั้น แต่พวกเขายังคงใช้พื้นที่ว่างบนดิสก์ ฉันเคยมีการคัดลอกไฟล์ในขณะที่ถ่ายโอนไฟล์โหมดผู้ใช้คนเดียวไปยังไดเรกทอรีที่ฉันไม่สามารถมองเห็นได้ยกเว้นใน usermode เดียว (เนื่องจากระบบไดเรกทอรีอื่น ๆ ที่ติดตั้งอยู่ด้านบนของพวกเขา)

เพิ่งสะดุดในหน้านี้เมื่อพยายามติดตามปัญหาบนเซิร์ฟเวอร์ภายใน

ในกรณีของฉันdf -hและdu -shไม่ตรงกันประมาณ 50% ของขนาดฮาร์ดดิสก์

ปัญหานี้เกิดจาก apache (httpd) ที่เก็บล็อกไฟล์ขนาดใหญ่ในหน่วยความจำซึ่งถูกลบออกจากดิสก์

สิ่งนี้ถูกติดตามโดยการเรียกใช้lsof | grep "/var" | grep deletedซึ่ง/varเป็นพาร์ติชันที่ฉันต้องการในการล้างข้อมูล

เอาท์พุทแสดงให้เห็นเส้นเช่นนี้:
httpd 32617 nobody 106w REG 9,4 1835222944 688166 /var/log/apache/awstats_log (deleted)

สถานการณ์ได้รับการแก้ไขแล้วโดยการรีสตาร์ท apache ( service httpd restart) และล้างพื้นที่ว่างในดิสก์ 2GB โดยอนุญาตให้ลบไฟล์ที่ถูกลบ

ฉันเห็นด้วยกับคำตอบของ OldTroll เป็นสาเหตุที่เป็นไปได้มากที่สุดสำหรับพื้นที่ "หายไป" ของคุณ

บน Linux คุณสามารถติดตั้งพาร์ติชันรูททั้งหมด (หรือพาร์ติชั่นอื่น ๆ สำหรับเรื่องนั้น) ไปยังอีกที่หนึ่งในระบบไฟล์ที่คุณพูด / mnt เช่นเพียงแค่ออก

mount -o bind / /mnt

จากนั้นคุณสามารถทำ

du -h /mnt

และดูสิ่งที่ใช้พื้นที่ของคุณ

Ps: ขออภัยที่เพิ่มคำตอบใหม่ไม่ใช่ความคิดเห็น แต่ฉันต้องการการจัดรูปแบบบางอย่างเพื่อให้โพสต์นี้สามารถอ่านได้

ดูสิ่งที่df -iพูด อาจเป็นได้ว่าคุณไม่มี inode ซึ่งอาจเกิดขึ้นหากมีไฟล์ขนาดเล็กจำนวนมากในระบบไฟล์นั้นซึ่งใช้ inode ที่มีอยู่ทั้งหมดโดยไม่ต้องใช้พื้นที่ว่างทั้งหมด

ในกรณีของฉันสิ่งนี้เกี่ยวข้องกับไฟล์ที่ถูกลบขนาดใหญ่ มันค่อนข้างเจ็บปวดในการแก้ไขก่อนที่ฉันจะพบหน้านี้ซึ่งทำให้ฉันอยู่บนเส้นทางที่ถูกต้อง

ในที่สุดฉันก็แก้ปัญหาโดยการใช้lsof | grep deletedซึ่งแสดงให้ฉันเห็นว่าโปรแกรมใดกำลังถือล็อกไฟล์ที่มีขนาดใหญ่มากสองไฟล์

ไฟล์ที่เปิดโดยโปรแกรมไม่ได้หายไปไหน (หยุดการใช้พื้นที่ดิสก์) เมื่อคุณลบไฟล์มันจะหายไปเมื่อโปรแกรมปิด โปรแกรมอาจมีไฟล์ชั่วคราวขนาดใหญ่ที่คุณ (และ du) มองไม่เห็น หากเป็นโปรแกรมซอมบี้คุณอาจต้องรีบู๊ตเพื่อล้างไฟล์เหล่านั้น

ลองใช้วิธีนี้เพื่อดูว่ากระบวนการ dead / hang ถูกล็อคในขณะที่ยังเขียนลงดิสก์อยู่หรือไม่: lsof | grep "/ mnt"

จากนั้นลองฆ่า PID ใด ๆ ที่ติดอยู่ (โดยเฉพาะอย่างยิ่งค้นหาบรรทัดที่ลงท้ายด้วย "(ถูกลบ"))

นี่เป็นวิธีที่ง่ายที่สุดที่ฉันพบในปัจจุบันเพื่อค้นหาไฟล์ขนาดใหญ่!

นี่คือตัวอย่างถ้ารูทเมาท์ของคุณเต็ม / (เมาท์ / รูท) ตัวอย่าง:

cd / (คุณอยู่ในรูท)

ls | xargs du -hs

ตัวอย่างผลลัพธ์:

 ถังขยะ 9.4M
 บูต 63M
 4.0K cgroup
 680K dev
 31 ล้านเป็นต้น
 บ้าน 6.3G
 lib 313M
 32M lib64
 พบ 16K ที่หายไป +
 สื่อ 61G
 4.0K mnt
 การเลือกใช้ 113M
 du: ไม่สามารถเข้าถึง `proc / 6102 / task / 6102 / fd / 4 ': ไม่มีไฟล์หรือไดเรกทอรีดังกล่าว
 0 proc
 19 ล้านรูต
 วิ่ง 840K
 19M sbin
 4.0K selinux
 srv 4.0K
 ร้านค้า 25G
 26 ล้าน tmp

จากนั้นคุณจะสังเกตเห็นว่าร้านค้ามีขนาดใหญ่ให้ทำร้าน ซีดี

และเรียกใช้อีกครั้ง

ls | xargs du -hs

ตัวอย่างผลลัพธ์: 
 สำรองข้อมูล 109M
 358 ล้าน fnb
 iso 4.0G
 8.0K ks
 พบ 16K ที่หายไป +
 47 ล้านรูต
 สคริปต์ 11M
 tmp 79M
 21G vms

ในกรณีนี้ไดเร็กทอรี vms คือ space hog

สำหรับฉันฉันต้องเรียกใช้sudo duเนื่องจากมีไฟล์นักเทียบท่าจำนวนมากภายใต้การ/var/lib/dockerที่ผู้ใช้ที่ไม่ใช่ sudo ไม่ได้รับอนุญาตให้อ่าน

ความเป็นไปได้อีกข้อหนึ่งที่ควรพิจารณา - คุณเกือบจะรับประกันว่าจะเห็นความแตกต่างใหญ่ถ้าคุณใช้นักเทียบท่าและคุณเรียกใช้ df / du ภายในคอนเทนเนอร์ที่ใช้โวลุ่มเมานต์ ในกรณีของไดเรกทอรีที่เชื่อมต่อกับไดรฟ์ข้อมูลบนโฮสต์นักเทียบท่า df จะรายงานผลรวม df ของ HOST สิ่งนี้ชัดเจนถ้าคุณคิดเกี่ยวกับมัน แต่เมื่อคุณได้รับรายงานของ "คอนเทนเนอร์ที่ไม่มีการเติมเต็มดิสก์!" ตรวจสอบให้แน่ใจว่าคุณตรวจสอบปริมาณการใช้เนื้อที่ของภาชนะบรรจุด้วยสิ่งdu -hs <dir>ต่างๆ

ดังนั้นฉันจึงมีปัญหานี้ใน Centos 7 เช่นกันและพบวิธีแก้ปัญหาหลังจากลองใช้สิ่งต่าง ๆ เช่น bleachbit และการทำความสะอาด / usr และ / var แม้ว่าพวกเขาจะแสดงเพียงประมาณ 7G ต่อครั้ง ยังคงแสดง 50G จาก 50G ที่ใช้ในพาร์ติชันรูท แต่แสดงให้เห็นเพียง 9G ของการใช้ไฟล์ เรียกใช้อูบุนตู cd สดและยกเลิกการต่อเชื่อมพาร์ติชั่น 50G ที่ละเมิด, เปิดเทอร์มินัลและวิ่ง xfs_check และ xfs_repair บนพาร์ติชั่น จากนั้นฉันติดตั้งพาร์ติชันใหม่และไดเรกทอรีที่หายไป + ได้พบกับ 40G จัดเรียงไฟล์ + ขนาดที่หายไปและพบไฟล์บันทึกข้อความขนาด 38G สำหรับใช้งานในที่สุดซึ่งเป็นข้อผิดพลาด mp3 ซ้ำแล้วซ้ำอีก ลบไฟล์ขนาดใหญ่และตอนนี้มีพื้นที่และการใช้งานดิสก์ของฉันเห็นด้วยกับขนาดพาร์ติชันของฉัน ฉันยังต้องการทราบวิธีรับบันทึกการอบไอน้ำเพื่อไม่ให้เติบโตอีกครั้งใหญ่

หากดิสก์ที่ติดตั้งเป็นโฟลเดอร์ที่ใช้ร่วมกันบนเครื่อง windows ดูเหมือนว่า df จะแสดงขนาดและการใช้ดิสก์ของดิสก์ทั้งหมดของ Windows แต่ du จะแสดงเฉพาะส่วนของดิสก์ที่คุณเข้าถึงด้วย (และติดตั้งอยู่) ดังนั้นในกรณีนี้ปัญหาจะต้องได้รับการแก้ไขในเครื่อง windows

สิ่งที่คล้ายกันเกิดขึ้นกับเราในการผลิตการใช้งานดิสก์ไปถึง 98% ทำการสอบสวนต่อไปนี้:

a) df -iสำหรับการตรวจสอบการใช้งาน inode การใช้งาน inode นั้นมี 6% ดังนั้นไฟล์ที่เล็กกว่าจึงไม่มาก

b) การติดตั้งrootและตรวจสอบไฟล์ที่ซ่อนอยู่ ไม่สามารถยื่นใด ๆเป็นพิเศษไฟล์ duผลลัพธ์เหมือนก่อนเมานต์

c) ในที่สุดตรวจสอบnginxบันทึก มันได้รับการกำหนดค่าให้เขียนลงดิสก์ แต่นักพัฒนาได้ลบไฟล์บันทึกโดยตรงซึ่งทำให้nginxบันทึกทั้งหมดในหน่วยความจำ เนื่องจากไฟล์/var/log/nginx/access.logนั้นถูกลบออกจากดิสก์โดยใช้rmไม่สามารถมองเห็นได้duแต่ไฟล์นั้นถูกเข้าถึงโดยnginxและยังคงเปิดอยู่

ฉันมีปัญหาเดียวกันที่กล่าวถึงในหัวข้อนี้ แต่ในหนึ่ง VPS ดังนั้นฉันได้ทดสอบทุกอย่างที่อธิบายไว้ในหัวข้อนี้ แต่ไม่ประสบความสำเร็จ การแก้ปัญหาการติดต่อสำหรับการสนับสนุนกับผู้ให้บริการ VPS ของเราที่ดำเนินการคำนวณใหม่โควต้าและการแก้ไขความแตกต่างของพื้นที่ของการและdf -hdu-sh /

ฉันพบปัญหานี้ในกล่อง FreeBSD วันนี้ ปัญหาคือว่าเป็นสิ่งประดิษฐ์ของvi( vimไม่แน่ใจว่าvimจะสร้างปัญหานี้หรือไม่) ไฟล์ดังกล่าวใช้พื้นที่มาก แต่ยังไม่ได้เขียนลงดิสก์อย่างสมบูรณ์

คุณสามารถตรวจสอบกับ:

$ fstat -f /path/to/mount/point |sort -nk8 |tail

สิ่งนี้จะดูไฟล์และประเภทที่เปิดอยู่ทั้งหมด (ตัวเลขผ่าน-n) โดยคอลัมน์ที่ 8 (คีย์-k8) เพื่อแสดงรายการสิบรายการสุดท้าย

ในกรณีของฉันรายการสุดท้าย (ใหญ่ที่สุด) มีลักษณะดังนี้:

bob      vi         12345    4 /var      97267 -rwx------  1569454080 rw

กระบวนการนี้หมายถึง (PID) 12345 บริโภค 1.46G (คอลัมน์ที่แปดหารด้วย1024³) ของดิสก์แม้ว่าจะไม่duสังเกตเห็นก็ตาม viเป็นเรื่องที่น่ากลัวเมื่อดูไฟล์ที่มีขนาดใหญ่มาก แม้ 100MB มีขนาดใหญ่สำหรับมัน 1.5G (หรือใหญ่กว่านั้นจริง ๆ ไฟล์) นั้นไร้สาระ

วิธีแก้ปัญหาคือsudo kill -HUP 12345(หากไม่ได้ผลฉันsudo kill 12345และถ้าสิ่งนั้นล้มเหลวความกลัวkill -9ก็จะเข้ามาเล่น)

หลีกเลี่ยงตัวแก้ไขข้อความในไฟล์ขนาดใหญ่ วิธีแก้ปัญหาตัวอย่างสำหรับการอ่านอย่างรวดเร็ว:

สมมติว่าความยาวของเส้นที่เหมาะสม:

• { head -n1000 big.log; tail -n1000 big.log } |vim -R -
• wc -l big.log |awk -v n=2000 'NR==FNR{L=$1;next}FNR%int(L/n)==1' - big.log |vim -R -

สมมติว่าบรรทัดที่มีขนาดใหญ่เกินสมควร:

• { head -c8000 big.log; tail -c8000 big.log } |vim -R -

การใช้งานเหล่านี้vim -Rแทนviewเพราะvimเกือบจะดีกว่าเสมอ ... เมื่อติดตั้งแล้ว อย่าลังเลที่จะส่งพวกเขาเข้าviewหรือvi -Rออก

หากคุณกำลังเปิดไฟล์ขนาดใหญ่เช่นนั้นเพื่อแก้ไขให้พิจารณาsedหรือawkหรือวิธีการเขียนโปรแกรมอื่น ๆ

ตรวจสอบว่าเซิร์ฟเวอร์ของคุณติดตั้ง ossec agent หรือไม่ หรือความสำเร็จบางอย่างกำลังใช้ไฟล์บันทึกที่ถูกลบ ในช่วงเวลาที่ผ่านมาตัวแทน ossec

ตรวจสอบ / สูญหาย + พบฉันมีระบบ (centos 7) และไฟล์บางส่วนใน / หายไป + พบกินพื้นที่ทั้งหมด