df ใน linux ไม่แสดงพื้นที่ว่างที่ถูกต้องหลังจากลบไฟล์

143

ฉันมีไฟล์เซิร์ฟเวอร์ที่ใช้ในการจัดเก็บไฟล์ ไฟล์อาจอยู่ที่นั่นเป็นเวลาหนึ่งสัปดาห์หรือเป็นเวลาหนึ่งปี น่าเสียดายที่เมื่อฉันลบไฟล์ออกจากเซิร์ฟเวอร์dfคำสั่งจะไม่สะท้อนถึงพื้นที่ว่าง ในที่สุดเซิร์ฟเวอร์ก็เต็ม ( dfแสดง 99%) และสคริปต์ของฉันไม่ได้ส่งไฟล์ใด ๆ เพิ่มเติมที่นั่นยกเว้นอาจมีพื้นที่ว่างสักสองสาม GB

ฉันติดnoatimeธงบนพาร์ติชั่นที่เมาท์ถ้ามันสร้างความแตกต่าง

linux filesystems disk-space-utilization

— Aminah Nuraini
แหล่งที่มา

สิ่งนี้เกิดขึ้นกับพาร์ติชั่นเดียวหรือทุกพาร์ติชั่นหรือไม่?

— เลด

มันเกิดขึ้นบนพาร์ติชันข้อมูลหลักของฉันซึ่งเป็นสิ่งเดียวที่ฉันสนใจเนื่องจากฉันเขียน / ลบไฟล์ลงบนมันเท่านั้น

โปรดให้ความกระจ่างแก่ฉันด้วยวิธีแก้ปัญหาหรือลิงก์ไปยังที่หนึ่ง

ระบบไฟล์อะไรบ้าง DF ทำสถิติของ superblock เป็นไปได้ว่าระบบไฟล์ของคุณไม่ได้อัพเดต sb inode คุณลองล้างแคชหรือยัง

— ถั่ว

ใช้ ext4 คุณจะล้างแคชได้อย่างไร

235

การลบชื่อไฟล์ไม่ได้เป็นการลบไฟล์จริงๆ กระบวนการอื่นกำลังถือไฟล์เปิดอยู่ทำให้ไม่สามารถลบได้ รีสตาร์ทหรือฆ่ากระบวนการนั้นเพื่อปล่อยไฟล์

ใช้

lsof +L1

เพื่อค้นหาว่ากระบวนการใดกำลังใช้ไฟล์ที่ถูกลบ (ไม่ได้เชื่อมโยง)

— Ignacio Vazquez-Abrams
แหล่งที่มา

2

ไฟล์ที่ถูกลบออกไม่สามารถเข้าถึงได้ในหนึ่งเดือนและกระบวนการเดียวที่เข้าถึงได้คือ nginx ดังนั้นจึงเป็นที่น่าสงสัย

39

+1 นอกจากนี้ "lsof + L1" จะบอกให้คุณทราบว่าโปรแกรมใดบ้างที่เปิดไฟล์ไว้

— pehrs

4

ในขณะที่รูทรัน "lsof -n | grep file" คุณจะประหลาดใจกับความยาวของไฟล์ที่สามารถใช้งานได้เนื่องจากกระบวนการที่เปิดไว้ไม่ว่าด้วยเหตุผลใด หากทุกอย่างล้มเหลวให้รีบูทฉันรู้สึกแย่ที่จะแนะนำ แต่มันจะทำให้แน่ใจได้อย่างแน่นอนว่าจะไม่มีสิ่งใดค้างอยู่บนไฟล์ ต่อชั่วโมง, lsof + L1 น่าจะเป็นวิธีที่ดีกว่า

— ScottZ

3

คุณเพิ่งช่วยฉัน! ลบไฟล์บันทึก 93G และไม่ได้รับพื้นที่คืนและไม่สามารถหาสาเหตุได้ ขอบคุณ

— ลุคลูกพี่ลูกน้อง

1

ตามบรรทัดเดียวกันและในกรณีนี้ช่วยผู้อื่นฉันลบไฟล์ nginx access.log ขนาดใหญ่ แต่สามารถเรียกคืนพื้นที่ได้หลังจากรีสตาร์ท nginx: บริการเริ่ม nginx แล้วเท่านั้น

— Nick

28

ดังที่อิกนาชิโอกล่าวถึงการลบไฟล์จะไม่เพิ่มพื้นที่ว่างจนกว่าคุณจะลบกระบวนการที่มีการจัดการแบบเปิดกับไฟล์นั้น

อย่างไรก็ตามคุณสามารถเรียกคืนพื้นที่โดยไม่ต้องฆ่ากระบวนการ สิ่งที่คุณต้องทำคือการลบไฟล์ descriptors

ก่อนอื่นให้ดำเนินการ lsof | grep ถูกลบเพื่อระบุกระบวนการที่เก็บไฟล์

[hudson@opsynxvm0055 log]$ /usr/sbin/lsof |grep deleted
java       8859   hudson    1w      REG              253,0 3662503356    7578206 /crucible/data/current/var/log/fisheye.out (deleted)

จากนั้นดำเนินการ:

cd /proc/PID/fd

แล้วก็

[hudson@opsynxvm0055 fd]$ ls -l |grep deleted
total 0
l-wx------ 1 hudson devel 64 Feb  7 11:48 1 -> /crucible/data/current/var/log/fisheye.out (deleted)

"1" จะเป็นตัวอธิบายไฟล์ ตอนนี้พิมพ์ "> FD" เพื่อเรียกคืนพื้นที่นั้น

> 1

คุณอาจจำเป็นต้องทำซ้ำการดำเนินการหากมีกระบวนการอื่น ๆ ถือไฟล์

— Adrián Deccico
แหล่งที่มา

1

สิ่งที่ไม่> FDทำอะไร?

— พ.ค.

มันจะลบไฟล์ descriptor ออกไป

— Adrián Deccico

2

>คำสั่งนี้มีชื่อหรือไม่? ฉันต้องเปลี่ยนจาก zsh เป็น bash เพื่อให้สามารถใช้งานได้ เป็นไปได้หรือไม่ที่จะรันบน zsh?

— ariera

1

มันคือการเปลี่ยนเส้นทางการส่งออกและดังนั้นจึงตัดทอนไฟล์ ความยาวจากนั้นจะเป็น "echo -n> 1" หรือ "true> 1" มันไม่ได้ลบ FD จริงๆมันแค่ชี้ไปที่ไฟล์เปล่าหลังจากนั้น

— eckes

8

ความเป็นไปได้อย่างหนึ่งคือไฟล์ที่คุณลบมีการอ้างอิงเพิ่มเติมในระบบไฟล์ หากคุณสร้างฮาร์ดลิงก์ชื่อไฟล์หลายแห่งจะชี้ไปที่ข้อมูลเดียวกันและข้อมูล (เนื้อหาจริง) จะไม่ถูกทำเครื่องหมายว่าว่าง / ใช้งานได้จนกว่าการอ้างอิงทั้งหมดจะถูกลบออก ก่อนที่คุณจะลบไฟล์ให้ stat พวกเขา (รายการชื่อ Links) หรือทำ ls -l ที่ไฟล์เหล่านั้น (ควรเป็นคอลัมน์ที่สอง)

หากปรากฎว่ามีการอ้างอิงไฟล์อื่น ๆ ฉันคิดว่าคุณจะต้อง ls -i ไฟล์เพื่อค้นหาหมายเลข inode แล้วทำการค้นหาด้วย -inum <inode-number> เพื่อค้นหา การอ้างอิงอื่น ๆ ไปยังไฟล์นั้น (คุณอาจต้องการใช้ -mount เพื่ออยู่ในระบบไฟล์เดียวกันด้วย)

— Kjetil Joergensen
แหล่งที่มา

4

ไฟล์ยังคงถูกล็อคโดยกระบวนการที่เปิดขึ้นมา เมื่อต้องการเพิ่มพื้นที่ว่างทำขั้นตอนเหล่านี้:

เรียกใช้sudo lsof | grep deletedและดูว่ากระบวนการใดกำลังเก็บไฟล์ ตัวอย่างผลลัพธ์:
```
$ sudo lsof | grep deleted
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF      NODE NAME
cron     1623 root    5u   REG   0,21        0 395919638 /tmp/tmpfPagTZ4 (deleted)
```
sudo kill -9 {PID}ฆ่ากระบวนการโดยใช้ ในตัวอย่างด้านบน PID คือ 1623
```
$ sudo kill -9 1623
```
เรียกใช้dfเพื่อตรวจสอบว่าพื้นที่ว่างเปล่าหรือไม่ หากยังคงเต็มคุณอาจต้องรอสักครู่แล้วตรวจสอบอีกครั้ง

— Aminah Nuraini
แหล่งที่มา

4

หากพาร์ติชันได้รับการกำหนดค่าให้จองพื้นที่ดิสก์บางส่วนสำหรับการใช้งานรูทบางส่วนdfจะไม่รวมพื้นที่นี้ตามที่มีอยู่

[root@server]# df -h
Filesystem            Size  Used Avail Use% Mounted on
...
/dev/optvol           625G  607G     0 100% /opt
...

แม้หลังจากที่พื้นที่จะถูกเรียกคืนโดยการลบไฟล์ / ไดเรกทอรีผู้ใช้ที่ไม่ใช่รูทจะไม่สามารถเขียนไปยังพาร์ทิชันเฉพาะ

คุณสามารถตรวจสอบได้อย่างง่ายดายว่าเป็นกรณีของคุณหรือไม่โดยการพยายามสร้างไฟล์บนอุปกรณ์ในฐานะผู้ใช้รูทและไม่ใช่รูท

นอกจากนี้คุณสามารถตรวจสอบการกำหนดค่าระบบไฟล์โดยการเรียกใช้

tune2fs -l <device> | egrep "Block count|Reserved block count

และคำนวณ% จริงด้วยตัวคุณเอง

ในการเปลี่ยนดิสก์% สงวนไว้สำหรับการใช้งานรูทเท่านั้นให้ดำเนินการ

tune2fs -m <percentage> <device>

— luka5z
แหล่งที่มา

1

คำตอบอื่น ๆ นั้นถูกต้อง: หากคุณลบไฟล์และพื้นที่ไม่ได้รับการปลดปล่อยมันมักจะเป็นเพราะไฟล์ยังคงเปิดอยู่หรือมีฮาร์ดลิงก์อื่น ๆ อยู่

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

ด้วยวิธีนี้คุณจะพบไฟล์ที่ยังคงใช้พื้นที่ได้อย่างรวดเร็วเนื่องจากมีฮาร์ดลิงก์ที่สอง มันจะแสดงพื้นที่ว่างที่ถูกลบไป แต่ไฟล์ที่เปิด (ตามที่ (ปฏิเสธสิทธิ์) ผมเชื่อว่าเพราะมันไม่สามารถอ่านชื่อไฟล์ได้

— sleske
แหล่งที่มา

1

เนื่องจากฉันรู้ว่าคุณหลายคนกำลังทำสิ่งนี้เพื่อ redhat in /varและไฟล์ gzipping ที่คาดว่า FS จะลดขนาดลง แต่มันจะโตขึ้น แต่เพียงตรวจสอบให้แน่ใจว่าคุณได้เริ่มระบบ syslog ใหม่ และ

lsof -v file

จะแสดงให้คุณเห็นอย่างใด

— user1802263
แหล่งที่มา

1

มันไม่ได้เพิ่มอะไรมาก คำตอบที่ได้รับการยอมรับครอบคลุมตรรกะที่อยู่เบื้องหลังนั้นในปี 2544 เมื่อคุณมี 50 ตัวแทนให้ใช้ความคิดเห็นหากคุณต้องการเพิ่ม qualifier ให้กับคำตอบที่มีอยู่

— Andrew B

0

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

— เฉินเลวี
แหล่งที่มา

0

ฉันกำลังใช้ EXT2, FSCK ช่วยฉันในสถานการณ์นี้ ลองใช้ shudown -F ทันทีหลังจากรีสตาร์ทและ fscks ฉันเห็นพื้นที่ว่างครึ่งหนึ่งที่ใช้แล้ว

— มาร์เซลลั
แหล่งที่มา

1

เรียน Marcellus ทางออกของคุณรวมอยู่ในคำตอบที่ยอมรับแล้ว และบางครั้งคุณไม่ต้องการที่จะทำรีบูตถ้าคุณไม่ได้บังคับให้ ...

— Deer Hunter

-1

ในการตรวจสอบว่าไฟล์ใดที่ถูกลบซึ่งครอบครองหน่วยความจำให้ป้อนคำสั่ง

 $ sudo lsof | grep deleted

มันจะแสดงไฟล์ที่ถูกลบที่เก็บหน่วยความจำ

จากนั้นฆ่ากระบวนการด้วย pid หรือชื่อ

$ sudo kill <pid>
$ df -h

ตรวจสอบตอนนี้คุณจะมีหน่วยความจำเดียวกัน

หากไม่พิมพ์คำสั่งด้านล่างเพื่อดูว่าไฟล์ใดครอบครองหน่วยความจำ

# cd /
# du --threshold=(SIZE)

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

— Javeed Shakeel
แหล่งที่มา

-4

เทอร์มินัลเปิดลองใช้คำสั่งนี้ df -Th ใช้คำสั่งนี้ต่อไป sudo du -h --max-depth = 1 / ในคำสั่งนี้คุณจะพบรายละเอียดการใช้ดิสก์จากนั้นเปิดเป็นผู้ใช้รูทลบไฟล์ (root-local-share-trash) และลบไฟล์ของคุณ

— Rilson
แหล่งที่มา