Disk dolu, du farklı söylüyor. Daha fazla araştırma nasıl yapılır?

Bir sunucuda bir SCSI diskim var (donanım Raid 1), 32G, ext3 dosya sistemi. dfbana diskin% 100 dolu olduğunu söyledi. 1G'yi silersem bu doğru olarak gösterilir.

Ben çalıştırmak Ancak, du -h -x /daha sonra dusadece 12G (kullandığım kullanıldığını söylüyor -xçünkü bazı Samba bağlar).

Öyleyse sorum, du ve df komutları arasındaki ince farklar değil, bu büyük farklılığa neyin sebep olduğunu nasıl bulabilirim?

Makineyi yanlış giden bir fsck için yeniden başlattım. Kaçmalı mıyım badblocks? lsofsilinmiş açık dosya olmadığını gösterir lost+found, boş ve mesaj dosyasında bariz bir uyarı / err / fail ifadesi yoktur.

Kurulum hakkında daha fazla bilgi istemek için çekinmeyin.

Bağlantı noktalarının altındaki dosyaları kontrol et. Sıklıkla, altında bir dosya veya dizinleri bulunan bir dosya sistemine bir dizin (sambaf) söylerseniz, bu dosyaları görme yeteneğini kaybedersiniz, ancak yine de temel diskte yer kaplıyorlar. Tek kullanıcı modundayken, dosyaları tek kullanıcı modu dışında (diğer dizin sistemlerinin üzerine monte edilmesinden dolayı) göremediğim dizinlere dökerken dosya kopyalarım oldu.

Yerel bir sunucuda bir sorunu bulmaya çalışırken bu sayfaya tökezledi.

Benim durumumda df -hve du -shsabit disk boyutunun yaklaşık% 50'si ile uyuşmuyor.

Bunun nedeni, büyük günlük dosyalarını diskten silinmiş bellekte tutan apache (httpd) 'dir.

Bu, temizlemem gereken bölümün lsof | grep "/var" | grep deletednerede /varolduğunu kontrol ederek izlendi .

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

Bu durumda durum apache'nin ( service httpd restart) yeniden başlatılmasıyla çözüldü ve silinen dosyalar üzerindeki kilitlerin silinmesine izin verilerek 2 gb disk alanı boşaltıldı.

OldTroll'un "eksik" alanınızın en muhtemel nedeni olduğuna cevabını kabul ediyorum.

Linux'ta, tüm kök bölümünü (veya bu konuda başka bir bölümü) dosya sistemindeki başka bir yere kolayca / mnt olarak söyleyebilirsiniz.

mount -o bind / /mnt

o zaman yapabilirsin

du -h /mnt

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

Ps: Yeni bir cevap ekleyip yorum yapamadığım için üzgünüm ama bu yazının okunabilmesi için biraz biçimlendirmeye ihtiyacım vardı.

Bak ne df -idiyor. Bu dosya sisteminde çok sayıda küçük dosya varsa ve bu durumda mevcut tüm alanı kullanmadan mevcut tüm inode'ları kullanan çok sayıda küçük dosya varsa, olabilecek inode olmayabilir.

Benim durumumda bunun büyük silinmiş dosyalar ile ilgisi vardı. Beni doğru yola koyan bu sayfayı bulmadan önce çözmek çok acı vericiydi.

Sonunda problemi kullanarak çözdüm, lsof | grep deletedhangi programın iki büyük günlük dosyasını tuttuğunu (toplam 5GB kullanılabilir 8GB kök bölümüm).

Bir program tarafından açılan dosyalar, silindiğinde aslında kaybolmaz (disk alanını tüketmeyi durdurur), program kapatıldığında kaybolur. Bir programın (ve du) göremediğiniz büyük bir geçici dosya olabilir. Bu bir zombi programıysa, bu dosyaları temizlemek için yeniden başlatmanız gerekebilir.

Bunu hala diske yazarken ölü / askıda bir işlemin kilitlenip kilitlenmediğini görmek için deneyin: lsof | grep "/ mnt"

Ardından sıkışmış PID'leri öldürmeyi deneyin (özellikle "(silindi" ile biten satırları arayın)

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

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

cd / (yani siz kökdesiniz)

ls | xargs du -hs

Örnek çıktı:

 9,4M bölmesi
 63M önyükleme
 4.0 K grubu
 680K dev
 31M vb
 6.3G ev
 313 milyon lib
 32M lib64
 16 K kayıp + bulundu
 61G medya
 4.0 bin ton
 113M opt
 du: `proc / 6102 / görev / 6102 / fd / 4 'dizinine erişemiyor: Böyle bir dosya veya dizin yok
 0 proc
 19M kökü
 840K koşusu
 19M sbin
 4.0K selinux
 4.0 bin srv
 25G mağazası
 26M tmp

o zaman mağazanın büyük olduğuna dikkat edersiniz, cd / store yapın.

ve tekrar koş

ls | xargs du -hs

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

Bu durumda, vms dizini uzay domuzudur.

Benim için, sudo olmayan bir kullanıcının okuma izninin olmadığı sudo duçok sayıda docker dosyası olduğu için çalıştırmam gerekiyordu /var/lib/docker.

Dikkate alınacak bir başka olasılık - liman işçisi kullanıyorsanız büyük bir tutarsızlık görmek neredeyse garantilidir ve birim montajı kullanan bir kap içinde df / du kullanırsınız. Liman işçisi ana bilgisayarındaki bir birime monte edilmiş bir dizinde, df, HOST'nin df toplamlarını bildirir. Bunu düşünürseniz bu açıktır, ancak “diski dolduran kaçak konteynır!” Hakkındaki bir rapor aldığınızda, kabın dosya alanı tüketimini benzer bir şeyle doğruladığınızdan emin olun du -hs <dir>.

Bu yüzden Centos 7'de de bu problemi yaşadım ve her ikisinde de sadece 7G olduğunu gösterseler de ağartma suyu ve temizlik / usr ve / var gibi bir sürü şeyi denedikten sonra bir çözüm buldum. Hala kök bölümünde kullanılan 50G 50G gösteriyordu ama sadece 9G dosya kullanımı gösterdi. Canlı bir ubuntu cd çalıştırdı ve rahatsız edici 50G bölümünü çıkardı, terminali açtı ve bölüme xfs_check ve xfs_repair'i koştu. Daha sonra bölümü yeniden monte ettim ve kayıp + bulunan dizinim 40G'ye genişledi. Boyutuna göre bulunan kayıp + sırasını sıraladı ve sonunda bir mp3 hatasını tekrar eden buhar için bir 38G metin günlük dosyası buldu. Büyük dosya kaldırıldı ve şimdi boş alan var ve disklerim kullanımı kök bölüm boyutumla aynı fikirde. Yine de buhar kütüğünün bu kadar büyük büyümemesini nasıl sağlayacağımı bilmek istiyorum.

Takılan disk bir Windows makinesinde paylaşılan bir klasörse, o zaman df tüm Windows diskinin boyutunu ve disk kullanımını gösterir, ancak du, yalnızca diske erişiminiz olan kısmını da gösterir. (ve monte edilmiştir). bu nedenle bu durumda sorunun Windows makinede çözülmesi gerekiyor.

Benzer bir şey başımıza üretimde oldu, disk kullanımı% 98'e çıktı. Aşağıdaki soruşturma yaptım:

a) df -iinode kullanımını kontrol etmek için, inode kullanımı% 6 idi, bu yüzden çok daha küçük dosyalar değildi.

b) rootGizli dosyaların takılması ve kontrol edilmesi. Herhangi dosyası olamazdı ekstra dosyaları. duSonuçlar montaj öncesiyle aynıydı.

c) Son olarak, kontrol edilen nginxgünlükleri. Diske yazacak şekilde yapılandırılmış, ancak bir geliştirici nginx, günlükleri bellekte tutmaya neden olacak şekilde doğrudan günlük dosyasını silmiş . Dosya /var/log/nginx/access.logkullanılarak diskten silindiği rmiçin, kullanımı görünmüyordu duancak dosyaya erişiliyordu nginxve bu nedenle hala açık tutuluyordu.

Bu konuda da aynı sorunu yaşadım, ancak bir VPS'de. Bu yüzden, bu konuda açıklanan her şeyi test ettim ancak başarılı olamadım. Solüsyon kota yeniden hesaplama yapılır ve uzay farkını ortadan bizim VPS sağlayıcı ile destek için bir temas oldu df -hve du-sh /.

Bugün bu problemi FreeBSD kutusuyla karşılaştım. Mesele bunun bir eserdi vi( bu sorunu yaratıp yaratmayacağından vimemin değil vim). Dosya yer kaplıyordu ancak diske tam olarak yazılmamıştı.

Şunlarla kontrol edebilirsiniz:

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

Bu, tüm açık dosyalara ve son on maddeyi gösteren -n8. sütuna (anahtar) göre (sayısal olarak ) sıralar -k8.

Benim durumumda, son (en büyük) giriş şöyle görünüyordu:

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

Bu işlem (PID) 12345, dufark etmemesine rağmen 1.46G (sekizinci sütun 1024 column ile bölünmüş) kullanıyordu . vison derece büyük dosyaları görüntülemek için korkunç; 100 MB bile bunun için büyük. 1.5G (veya bu dosyanın büyüklüğünde olmasına rağmen) çok saçma.

Çözüm ise sudo kill -HUP 12345(işe yaramadıysa, ben yapardım sudo kill 12345ve bu da başarısız olursa, korkak kill -9devreye girerdi).

Büyük dosyalarda metin editörlerinden kaçının. Hızlı kaymağını almak için örnek geçici çözümler:

Makul çizgi uzunlukları varsayarak:

• { 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 -

Makul olmayan geniş hat (lar) varsayarak:

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

vim -RYerine bu kullanım viewçünkü vimyüklü olduğunda neredeyse her zaman iyidir. Bunları içine viewveya içine yerleştirmekten çekinmeyin vi -R.

Gerçekten düzenlemek için çok büyük bir dosyayı açıyorsanız, düşünün sedveya awkbaşka bir programatik yaklaşım kullanın.

Sunucunuzda ossec aracısının kurulu olup olmadığını kontrol edin. Veya bazı işlemler silinen günlük dosyalarını kullanıyor. Bir zaman önce ossec ajanıydı.

kontrol et / kayıp + bulundu, bir sistemim vardı (centos 7) ve / kayıp + içindeki dosyanın bir kısmı tüm alanı yedi.