dosyaları silmek ancak disk alanı hala dolu


26

Eski CentOS 5.6 kutusuyla ilgileniyor, lvm kurulumuna gerek kalmadan, kök dosya sistemim / dolu, ihtiyacım olmayan birçok eski günlük dosyasını ve uygulama dosyalarını temizledim, bu da sistemimin boyutundan 2-5GB daha büyüktü. hala o diskin dolu olduğunu bildirir.

[root@tornms1 ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda3             130G  124G     0 100% /
/dev/sdb1             264G  188M  250G   1% /data
/dev/sda1              99M   24M   71M  26% /boot
tmpfs                 2.0G     0  2.0G   0% /dev/shm



[root@tornms1 ~]# mount
/dev/sda3 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/sdb1 on /data type ext3 (rw)
/dev/sda1 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)

Bundan sonra ne yapmam gerektiği hakkında fikrin var mı? Maalesef kutuyu yeniden başlatmak şu anda bir seçenek değil.


1
Aptalca bir soru sorduğum için üzgünüm, ama /.Trash/boş olduğundan emin oldun mu? Yaptın sudo rm -Rf ~/.Trash/*
Sanat Gertner

Bu bir sunucudur, xwindow yüklü değil, bu yüzden root hesabımda .trash klasörüm yok.
user1007727

Kötüyüm, tüm unix benzeri sistemlerde /.Trash/ olduğunu varsaydım.
Sanat Gertner

Ayrıca sync ( linux.die.net/man/8/sync ) komutunu deneyebilirsiniz, belki de tüm işlemleriniz hala önbelleğe alınır.
weberik

Yanıtlar:


38

Burada iki şey olabilir.

Öncelikle , dosya sisteminiz yalnızca rootyazabilecek bir alan ayırdı , böylece normal kullanıcılar disk alanı bittiğinde kritik sistem işleminin üstesinden gelmiyor. Bu nedenle 124G'nin 130G'yi kullandığını ancak sıfırın kullanılabilir olduğunu görüyorsunuz. Belki de sildiğiniz dosyalar kullanımı bu noktaya getirmiştir, ancak normal kullanıcılar için eşiğin altında değildir.

Bu sizin durumunuz ve çaresizseniz, ayrılan alan miktarını değiştirebilirsiniz root. % 1'e düşürmek için (varsayılan% 5'tir), komutunuz

# tune2fs -m 1 /dev/sda3

İkincisi , işletim sistemi hala açık olan silinen dosyalar için disk alanı bırakmaz. Apache'nin günlük dosyalarından birini sildiyseniz (varsa), alanı boşaltmak için Apache'yi yeniden başlatmanız gerekir.


1
evet, ikincisi önce olmalı!
mulya

Bu soru & cevap (lar) daha fazla bilgi ekleyin superuser.com/questions/444269/… .
luka5z


10

2 diski elde etmenin diğer yolları tam sorun:

1) bir bağlantı noktasının altına gizlenmiş: linux bir bağlantı noktasının altında "gizli" dosyalara sahip tam bir disk gösterecektir. Sürücüye yazılan verileriniz varsa ve üzerine başka bir dosya sistemi bağladıysanız, linux dosyaları bağlama noktasının altında göremeseniz de disk kullanımını doğru şekilde not eder. Eğer nfs mount'larınız varsa, bunları takmayı ve mount'dan önce bu dizinlere yanlışlıkla bir şey yazılıp yazılmadığını kontrol etmeyi deneyin.

2) bozuk dosyalar: Bunu bazen pencerelerde SMB aracılığıyla linux dosya aktarımına görüyorum. Bir dosya dosya tanımlayıcısını kapatmıyor ve 4GB'lık bir çöp kutusuyla kapatılıyor.

Bunu düzeltmek daha sıkıcı olabilir, çünkü dosyanın bulunduğu alt dizini bulmanız gerekir, ancak dosyanın kendisi kolayca çıkarılabilir olduğundan düzeltilmesi kolaydır. Kullandığım dukomutu ve dosya alanı nerede kullanıldığını öğrenmek için bir kök subdirs ait listeleme yapmak.

cd /
du -sh ./* 

Üst seviye dizinlerin sayısı genellikle sınırlıdır, bu yüzden hangi alt dizinin alan domuz olduğunu görmek için insan tarafından okunabilen bayrağını ayarladım -h.

Sonra sorunlu çocuğa cd verin ve içindeki tüm öğeler için işlemi tekrarlayın. Bunu büyük öğeleri tespit etmeyi kolaylaştırmak için du'yu hafifçe değiştiririz ve bir sıralama yaparız.

cd /<suspiciously large dir>
du -s ./* | sort -n

tüm dosyalar ve dizinler için byte boyutuna göre en küçük ve en büyük çıktılar üretir

4          ./bin 
462220     ./Documents
578899     ./Downloads
5788998769 ./Grocery List

Büyük boy dosyayı bulduğunuzda, genellikle sadece onu silebilirsiniz.


Harika ipuçları! Du altında / kullanarak klasörleri izledim ve android SDK altında son derece büyük sistem görüntüleri buldum. Onları
sildim

4

Lsof ile hangi dosyaların açık olduğunu öğrenebilirsiniz. Çok fazla çıktı üretebildiğim için, aşağıdaki örnekte log ile biten satırlarla sınırlı kalıyorum:

# lsof | grep log$
rsyslogd   2109     syslog    0u     unix 0xffff88022fa230c0      0t0       8894      /dev/log
rsyslogd   2109     syslog    1w      REG              252,6    62393         26 /var/log/syslog
rsyslogd   2109     syslog    2w      REG              252,6   113725        122 /var/log/auth.log
rsyslogd   2109     syslog    3u     unix 0xffff88022fa23740      0t0       8921 /var/spool/postfix/dev/log
rsyslogd   2109     syslog    5w      REG              252,6    65624        106 /var/log/mail.log
/usr/sbin  2129       root    2w      REG              252,6    93602         38 /var/log/munin/munin-node.log
/usr/sbin  2129       root    4w      REG              252,6    93602         38 /var/log/munin/munin-node.log
...

1

Bazı dosyalar silinir ancak yine de bir işlem tarafından kullanılıyorsa, o zaman alan serbest bırakılmaz. Bu durumda ya dosyayı kullanan bir işlemi yeniden başlatın ya da dosyayı geçersiz kılın. Bu dosyaları silmek yerine boşa çıkarmak her zaman iyi bir uygulamadır. Silinen dosyaları bulmak, ancak yine de bazı işlemler tarafından kullanılıyor

#lsof +L1

işlem kimliği ve dosya tanımlayıcısı verecektir. Silinen dosyayı dosya tanıtıcısına göre boş bırakmak için

#echo "" > /proc/$pid/fd/$fd 

1

Komutu yazın

#lsof +L1

Silinen alıntı ile hafızayı tutan dosyaların listesini gösterecektir.

Not pid dosyasının (Süreç kimliği)

Süreci öldür

#kill <pid>

Bellek işlem tarafından serbest bırakılacak

Komutla kontrol et

#df -h

0

Ayrıca, açıklanmış olana ek olarak, sorun aynı sunucudaki başka bir bağlı disk cihazında silinmiş dosya dizininin başka bir bağlantı noktası olması olabilir. Geçerli montajları ve fstab girişlerini kontrol edin.


0

Vahşi doğada gözlemlenen asıl sorun:

Emin gerçek dosyaları silerek ve olduğunuzdan emin olun sembolik bağları dosyalara. Bu, özellikle günlük dosyaları için geçerli olabilir.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.