Soru Disk dolu, farklı anlatıyor. Daha fazla araştırma nasıl yapılır?


Bir sunucuda (donanım Raid 1), 32G, ext3 filesytem bir SCSI disk var. df diskin% 100 dolu olduğunu söyledi. 1G'yi silersem, bu doğru şekilde gösterilir.

Ancak, eğer bir du -h -x / sonra du sadece 12G'nin kullanıldığını söyledi -x bazı Samba bağları nedeniyle).

Bu yüzden benim sorum, du ve df komutları arasındaki ince farklarla değil, bu büyük farka neden olan şeyi nasıl bulabildiğim hakkında mı?

Makineyi w / out hatalarına giden bir fsck için yeniden başlattım. Koşmalı mıyım badblocks? lsof silinen dosyaları açmamı gösterir, lost+found boş ve mesajlar dosyasında belirgin bir uyarı / err / fail ifadesi yok.

Kurulum hakkında daha fazla bilgi istemekte çekinmeyin.


91
2018-05-30 12:29


Menşei


Bu, soruna çok yakın: linux - du vs. df farkı (serverfault.com/questions/57098/du-vs-df-difference). Çözüm, OldTroll'un yanıtladığı gibi bir bağlama noktası altındaki dosyalardı. - Chris Ting


Cevaplar:


Montaj noktaları altında bulunan dosyaları kontrol edin. Sık sık bir dosya veya dizin altında bir dosya sistemi üzerinde bir dizin (bir sambaf) söylerseniz, bu dosyaları görme yeteneğini kaybedersiniz, ancak yine de temel diskte yer kaplarlar. Tek kullanıcı modunda tek bir kullanıcı modunda dosyaları tek bir kullanıcı dışında göremediğim dizinlere dosya kopyalarım vardı (diğer dizin sistemlerine bağlı olarak).


88
2018-05-30 12:35



Bu gizli dosyaları, dizinleri kaldırmak zorunda kalmadan bulabilirsiniz. Nasıl olduğunu açıklayan Marcel G'nin cevabına bir bakın. - mhsekhavat
Bunu cevabınızda yapmak için CLI komutlarını göstermelisiniz - Jonathan
Bunun sizin için anlamlı olmadığını düşündüğünüzde KONTROL EDİN! - Chris


Yerel bir sunucuda bir sorunu takip etmeye çalışırken bu sayfada sadece tökezledi.

Benim durumumda df -h ve du -sh Sabit disk boyutunun yaklaşık% 50'si uyuşmuyor.

Bu, diskten silinen bellekte büyük günlük dosyalarını tutan apache (httpd) neden oldu.

Bu koşarak izlendi lsof | grep "/var" | grep deleted nerede /var Temizlemem gereken bölümdü.

Çıktı böyle çizgiler gösterdi:
httpd 32617 nobody 106w REG 9,4 1835222944 688166 /var/log/apache/awstats_log (deleted)

Durum daha sonra apache yeniden başlatılarak çözüldü (service httpd restart) ve silinmiş dosyaların kilitlerinin temizlenmesini sağlayarak 2 gb disk alanı temizledim.


76
2018-03-12 11:10



Benim için, programı durdurduktan sonra bile çıkmayan kilitler (zombiler?). Yapmak zorundaydım kill -9 'pid' kilitleri serbest bırakmak için. örneğin: httpd için olurdu kill -9 32617. - Micka
Küçük not: Koşmanız gerekebilir lsof gibi sudo ya da açık olan tüm dosya tanıtıcıları görünmeyecek - ChrisWue
Buna her gün bir günlük dosyasına birkaç konser ekleyen H2 ile girdim. H2 (yavaş) yeniden başlatmak yerine sudo truncate -s0 /proc/(h2 PID)/(descriptor number obtained from ls /proc/h2pid/fd). - Desty
Benim durumumda, yeniden başladığında bile httpd boşluk serbest bırakılmadı. Koştuğumda /etc/init.d/rsyslog restart çalıştı: D - Thanh Nguyen Van
Grepsleri atlayabilir ve sadece lsof -a +L1 /var, nerede -a anlamına gelir ve tüm koşullar (varsayılan OR'dir), +L1 sadece listedeki dosyaların listesi 1'den küçük sayılar (yani, açık dosya tanımlayıcılarına sahip silinmiş dosyalar) ve /var o bağlama noktasının altındaki dosyalara kısıtlar - kbolino


OldTroll'un cevabını "eksik" alanınız için en olası neden olarak kabul ediyorum.

Linux üzerinde, kök dizinini (veya bu konuyla ilgili herhangi bir başka bölümü), sistem sistemindeki başka bir yere kolayca yeniden yerleştirebilirsiniz.

mount -o bind / /mnt

o zaman sen yapabilirsin

du -h /mnt

ve uzanı neyin kullandığını gör.

Ps: yeni bir cevap eklemek için üzgünüm ve bir yorum değil ama bu yazı için okunabilir olması için bazı biçimlendirmeye ihtiyacım vardı.


40
2018-05-30 13:54



Bu ipucu için çok teşekkürler. Büyük, "gizli" dosyalarımı kesinti yaşamadan bulup silmeme izin verin! - choover
Teşekkürler - bu docker sabit diskimi diffs ile doldurduğunu gösterdi /var/lib/docker/aufs/diff/ - naught101


Ne olduğunu gör df -i diyor. Mevcut dosya alanını tüketmeden tüm mevcut inode'ları kullanan çok sayıda küçük dosya varsa, söz konusu düğümlerden çıkmış olabilirsiniz.


23
2018-05-30 14:10



Bir dosyanın boyutu ve bir dosya sistemi üzerinde aldığı alan miktarı iki ayrı şeydir. Dosyalar ne kadar küçük olursa, aralarındaki farklılık o kadar büyük olur. Dosya boyutlarını toplayan ve bunları karşılaştırmak için bir komut dosyası yazarsanız du -s Aynı alt ağacın, burada durum böyle olursa iyi bir fikir elde edersiniz. - Marcin


Benim durumumda bu büyük silinen dosyaları ile ilgisi vardı. Bu sayfayı bulmadan önce çözmek için oldukça acı vericiydi, bu beni doğru yola koydu.

Sonunda problemi kullanarak çözdüm lsof | grep deletedHangi programın iki çok büyük günlük dosyası tuttuğunu gösterdim (toplam 8GB'lık mevcut 8GB'lık kök bölümüm).


16
2017-11-14 18:15



Bu cevap, neden log dosyalarını kök bölmesinde sakladığınızı merak ediyor, özellikle de küçük bir tane ... ama her biri için ... - α CVn
Benzer bir sorunla karşılaştım, silinen dosyayı kullanan tüm uygulamaları yeniden başlattım, sanırım hala büyük bir silinmiş dosyada tutan bir zombi işlemi vardı. - user1965449
Bu bizim için bir dosya, dosya adı açık dosya olarak bilinen bir dosya işleme linux uygulaması oldu. - Pykler


Bir program tarafından açılmış olan dosyalar, onları sildiğinizde, aslında disk alanlarını (disk alanı tüketmeyi durdurur) gitmez, program kapatıldığında gider. Bir program sizin (ve du) göremediğiniz devasa bir geçici dosyaya sahip olabilir. Bir zombi programıysa, bu dosyaları temizlemek için yeniden başlatmanız gerekebilir.


5
2018-05-30 12:51



OP sistemi yeniden başlattığını ve sorunun devam ettiğini söyledi. - OldTroll
Dosyalardaki kilitleri serbest bırakmayacak zombilerim vardı. kill -9 'pid' kilitleri serbest bırakmak ve disk alanını geri almak için. - Micka


Bu, büyük dosyaları bulmak için bugüne kadar bulduğum en kolay yöntem!

Kök montajınız tam / (mount / root) ise bir örnek Örnek:

cd / (böylece kökündesin)

ls | xargs du -hs

Örnek çıktı:

 9.4M çöp kutusu
 63M önyükleme
 4.0K grup
 680K dev
 31M vb
 6.3G ev
 313M lib
 32M lib64
 16 bin kayıp bulundu
 61G medya
 4.0 K mnt
 113M opt
 du: `proc / 6102 / task / 6102 / fd / 4 'erişemiyor: Böyle bir dosya ya da dizin yok
 0 proc
 19M kökü
 840K koş
 19m sbin
 4.0K selinux
 4.0K srv
 25G mağaza
 26 M tmp

o zaman fark edeceksin mağaza büyük yapmak cd / mağaza

ve tekrar koş

ls | xargs du -hs

Örnek çıktı:
 109M yedek
 358M fnb
 4.0G iso
 8.0 K ks
 16 bin kayıp bulundu
 47M kökü
 11M komut dosyaları
 79M tmp
 21G vms

Bu durumda vms dizini boşluk hog'dur.


4
2018-06-26 13:05



Neden daha basit araçlar kullanmıyorsunuz? baobab? (görmek marzocca.net/linux/baobab/baobab-getting-started.html) - Yvan
Hımm ls + xargs overkill gibi görünüyor du -sh /* kendi başına gayet iyi çalışıyor - ChrisWue
ncdu hakkında bilmiyorsanız ... bana daha sonra teşekkür edeceğim: dev.yorhel.nl/ncdu - Troy Folger


Hala diske yazarken bir ölü / asılı işlemin kilitli olup olmadığını görmek için bunu deneyin: lsof | grep "/ mnt"

Daha sonra sıkışmış PID'leri öldürmeyi deneyin (özellikle "biten" satırları arayın (silindi ")).


3
2018-06-26 10:38



Teşekkürler! SFTP sunucu işleminin silinen dosyayı tuttuğunu buldum. - lyomi