Linux'ta df, dosya kaldırıldıktan sonra doğru boş alan göstermiyor

Dosyaları depolamak için kullanılan dosya sunucularım var. Dosyalar orada bir hafta veya bir yıl boyunca kalabilir. Ne yazık ki, dosyaları sunucudan kaldırdığımda, dfkomut serbest kalan alanı yansıtmıyor. Sonuçta, sunucu doluyor ( df% 99 gösteriyor) ve betiğim orada birkaç dosya daha yayınlamıyor, orada birkaç düzine GB boş alan olması dışında.

noatimeHerhangi bir fark yaratırsa monte edilmiş bölmelerde bayrak aldım .

Dosya adını silmek aslında dosyayı silmez. Diğer bazı işlemler dosyayı açık tutuyor ve silinmemesini sağlıyor; dosyayı serbest bırakmak için bu işlemi yeniden başlatın ya da öldürün.

kullanım

lsof +L1

Hangi işlemin silinmiş (bağlantısız) bir dosya kullandığını bulmak için.

Ignacio’nun söylediği gibi, dosyayı silmek için açık tutamaçları olan işlemleri silene kadar dosyayı boş bırakmaz.

Bununla birlikte, süreçleri öldürmeden alanı geri kazanabilirsiniz. Tek yapmanız gereken dosya tanımlayıcılarını kaldırmak.

İlk önce lsof | grep, dosyayı tutan işlemi tanımlamak için silindi

[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)

Ardından yürütün:

cd /proc/PID/fd

sonra

[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", dosya tanıtıcısı olacaktır. Şimdi bu alanı geri kazanmak için "> FD" yazın.

> 1

Dosyayı tutan başka işlemler varsa işlemi tekrarlamanız gerekebilir.

Bir olasılık, sildiğiniz dosyaların dosya sisteminde daha fazla referansa sahip olmasıdır. Sabit bağlantılar oluşturduysanız, birkaç dosya adı aynı verilere işaret eder ve veriler (gerçek içerikler) tüm referanslar kaldırılıncaya kadar serbest / kullanılamaz olarak işaretlenmez. Dosyaları silmeden önce, bunları stat (İsimli Bağlantılar) olarak adlandırın veya üzerine ls -l yapın (ikinci sütun olmalıdır).

Dosyalara başka bir yerden referans verildiği ortaya çıkarsa, inode numarasını bulmak için ls -i dosyalarına ihtiyacınız olacak ve sonra bulmak için -inum <inode-number> ile bir arama yapmanız gerekecek. bu dosyaya yapılan diğer referanslar (muhtemelen aynı dosya sisteminde de kalmak için -çoğunu kullanmak isteyebilirsiniz).

Dosya açma işlemi tarafından hala kilitli. Yer kazanmak için şu adımları izleyin:

1. Çalıştırın sudo lsof | grep deletedve hangi işlemin dosyayı tuttuğunu görün. Örnek sonuç:

   $ 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)
   

2. Kullanarak işlemi öldürün sudo kill -9 {PID}. Yukarıdaki örnekte, PID 1623'tür.

   $ sudo kill -9 1623
   

3. Alanın dfboş olup olmadığını kontrol etmek için çalıştırın . Hala doluysa, belki birkaç saniye beklemeniz ve tekrar kontrol etmeniz gerekir.

Bölüm, disk alanının belirli bir bölümünü yalnızca kök kullanımı için ayırmak üzere yapılandırılmışsa df, bu alanı kullanılabilir şekilde içermeyecektir.

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

Dosyalar / dizinler silinerek alan geri kazanıldıktan sonra bile, root olmayan kullanıcılar belirli bölümlere yazı yazamazlar.

Bir cihazda root ve root olmayan kullanıcı olarak bir dosya oluşturmaya çalışarak durumunuzun bu olup olmadığını kolayca kontrol edebilirsiniz.

Ek olarak çalıştırarak dosya sistemi yapılandırmasını kontrol edebilirsiniz.

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

ve gerçek yüzdeyi kendi başınıza hesaplayabilirsiniz.

Yalnızca root kullanımı için ayrılmış% diskini değiştirmek için çalıştır

tune2fs -m <percentage> <device>

Diğer cevaplar doğrudur: Bir dosyayı silerseniz ve alan boşaltılmazsa, bunun nedeni genellikle dosyanın hala açık kalması ya da dosyada başka bağlantılar olması olabilir.

Sorun gidermeye yardımcı olmak için, size sürücü alanının nerede harcandığını bildiren bir araç kullanın: duNereye gittiğine dair genel bir bakış elde etmek için kullanabilirsiniz . Daha da iyisi, suçluyu avlamak için xdiskusage (bunun gibi pek çok şey var) gibi grafiksel bir araç kullanın . xdiskusage ve arkadaşları, alanın nereye gittiğini bulmak için en büyük uzay domuzlarını araştırmanıza izin verir.

Bu şekilde, ikinci bir hardlink nedeniyle hala yer kaplayan dosyaları hızla bulacaksınız. Aynı zamanda silinmiş yer işgalini de gösterir, ancak açık dosyalar (izin reddedildiği gibi, dosya adını okuyamadığı için).

Bir /vartonunuz bunu redhat için yapıyor ve FS'nin büzülmesini bekleyen dosyaların gzipping olduğunu biliyorum , ancak bunun yerine büyüyor, yalnızca syslog restart hizmetini verdiğinizden emin olun. ve

lsof -v file

Bunu nasıl olsa sana gösteririm.

Bir seçenek daha: Sürekli veri oluşturan bir işlem nedeniyle disk dolu olabilir: günlükler, çekirdekler ve benzerleri. Alanın gerçekten serbest bırakılması ancak derhal doldurulması mümkündür. Aslında böyle bir durum gördüm. dfBu durumda sadece delik resmi vermez. duDaha fazlasını öğrenmek için kullanın .

EXT2 kullanıyorum, FSCK bu durumda bana yardımcı oldu. Shudown -F şimdi deneyin, bazı yeniden başlatma ve fscks sonra, yarı kullanılmış alan görüyorum.

Hangi silinmiş dosyaların hafızada olduğunu kontrol etmek için komutu girin.

 $ sudo lsof | grep deleted

Belleği tutan silinmiş dosyaları gösterecektir.

Öyleyse işlemi pid veya isim ile öldür

$ sudo kill <pid>
$ df -h

Şimdi kontrol et, aynı hafızaya sahip olacaksın.

Hangi dosyanın belleği kapladığını görmek için aşağıdaki komutu yazın.

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

Hangi dosyaların eşik boyutunun üzerinde olduğunu gösteren herhangi bir boyuttan bahsedin ve sakladığınız hafızayı bulacağınız dosyayı silin

terminali aç, bu komutu dene df -Bu sonraki komutu kullan, sudo du -h --max-depth = 1 / bu komutta disk kullanım detayını bulacaksın ve kök kullanıcı olarak açılacak dosyayı sil (root-local-share-trash) ve dosyanızı silin