Inode Kullanımı Nasıl Ücretsiz?

Burada inode kullanımı% 100 ( df -ikomut kullanarak ) olan bir disk sürücüsü var . Ancak, dosyaları önemli ölçüde sildikten sonra kullanım% 100 olarak kalır.

Peki bunu yapmanın doğru yolu nedir?

Daha az disk alanı kullanan bir disk sürücüsünün daha yüksek disk alanı kullanan disk sürücüsüne göre daha yüksek Inode kullanımına sahip olması nasıl mümkün olabilir?

Kullanılan inode sayısını azaltacak çok fazla dosya sıkıştırmam mümkün mü?

Disk dolu olmasa bile bir diskin çok sayıda inot kullanması oldukça kolaydır.

Bir dosyaya bir inode tahsis edilir, bu nedenle, her biri 1 baytın tamamı varsa, diskiniz bitmeden çok önce inode'unuz tükenir.

Dosyaların birden çok sabit bağlantısı varsa, dosyaları silmenin inode sayısını azaltmaması da mümkündür. Söylediğim gibi, inodes dizin girdisine değil dosyaya aittir . Bir dosyanın kendisine bağlı iki dizin girişi varsa, birini silmek inode'u serbest bırakmaz.

Ayrıca, bir dizin girdisini silebilirsiniz, ancak çalışan bir işlemde hala dosya açıksa, inode serbest bırakılmaz.

İlk tavsiyem, yapabileceğiniz tüm dosyaları silmek, ardından dosyaları açık tutarak hiçbir işlem kalmamasını sağlamak için kutuyu yeniden başlatmak olacaktır.

Bunu yaparsanız ve hala bir sorununuz varsa, bize bildirin.

Bu arada, çok sayıda dosya içeren dizinleri arıyorsanız, bu komut dosyası yardımcı olabilir:

#!/bin/bash
# count_em - count files in all subdirectories under current directory.
echo 'echo $(ls -a "$1" | wc -l) $1' >/tmp/count_em_$$
chmod 700 /tmp/count_em_$$
find . -mount -type d -print0 | xargs -0 -n1 /tmp/count_em_$$ | sort -n
rm -f /tmp/count_em_$$

Çok şanssızsanız, tüm düğümlerin yaklaşık% 100'ünü kullandınız ve scipt oluşturamazsınız. Bunu ile kontrol edebilirsiniz df -ih.

O zaman bu bash komutu size yardımcı olabilir:

sudo find . -xdev -type f | cut -d "/" -f 2 | sort | uniq -c | sort -n

Ve evet, bu zaman alacaktır, ancak dizini en fazla dosyayla bulabilirsiniz.

Benim durumum, inode dışında olduğum ve yapabileceğim her şeyi silmiştim.

$ df -i
Filesystem     Inodes  IUsed  IFree IUse% Mounted on
/dev/sda1      942080 507361     11  100% /

Ben bir ubuntu 12.04LTS üzerinde ve eksik paketi nedeniyle apt kırık çünkü yaklaşık 400.000 inode aldı eski linux çekirdekleri kaldıramadı. Ve yeni paketi yükleyemedim çünkü inode dışındaydım, bu yüzden takıldım.

Yaklaşık 10.000 inode boşaltmak için birkaç eski linux çekirdeğini el ile sildim

$ sudo rm -rf /usr/src/linux-headers-3.2.0-2*

Bu, eksik paketi yüklememe ve uygunluğumu düzeltmeme izin vermek için yeterliydi

$ sudo apt-get install linux-headers-3.2.0-76-generic-pae

ve sonra eski linux çekirdeklerinin geri kalanını uygun şekilde çıkarın

$ sudo apt-get autoremove

şimdi işler çok daha iyi

$ df -i
Filesystem     Inodes  IUsed  IFree IUse% Mounted on
/dev/sda1      942080 507361 434719   54% /

Çözümüm:

Bunun bir inode problemi olup olmadığını bulmaya çalışın:

df -ih

Büyük düğüm sayısı olan kök klasörleri bulmaya çalışın:

for i in /*; do echo $i; find $i |wc -l; done

Belirli klasörleri bulmaya çalışın:

for i in /src/*; do echo $i; find $i |wc -l; done

Bu linux başlıklarıysa, en eski olanları kaldırmayı deneyin:

sudo apt-get autoremove linux-headers-3.13.0-24

Şahsen onları bağlı bir klasöre taşıdım (çünkü benim için son komut başarısız oldu) ve en son yüklü:

sudo apt-get autoremove -f

Bu benim sorunumu çözdü.

Ben aynı sorun vardı, php dizin oturumlarını kaldırarak düzeltildi

rm -rf /var/lib/php/sessions/

/var/lib/php5Eski bir php sürümü kullanıyorsanız altında olabilir .

Aşağıdaki izinle yeniden oluşturun

mkdir /var/lib/php/sessions/ && chmod 1733 /var/lib/php/sessions/

Debian'daki dizin için varsayılan olarak izin gösterildi drwx-wx-wt(1733)

Bunu, bir spam saldırısının ardından bir HostGator hesabında (tüm barındırmalarına inode sınırları koyan) yaşadık. /Root/.cpanel/comet içinde çok sayıda kuyruk kaydı bıraktı. Bu gerçekleşirse ve ücretsiz inode'unuz yoksa, bu cpanel yardımcı programını kabuk üzerinden çalıştırabilirsiniz:

/usr/local/cpanel/bin/purge_dead_comet_files

Çok sayıda dosyayı silmek için RSYNC'yi kullanabilirsiniz

rsync -a --delete blanktest/ test/

İçinde 0 dosya bulunan blanktest klasörü oluşturun ve komut, test klasörlerinizi çok sayıda dosyayla senkronize edecektir (Bu yöntemi kullanarak yaklaşık 5 milyon dosyayı sildim).

Sayesinde http://www.slashroot.in/which-is-the-fastest-method-to-delete-files-in-linux

eaccelerator PHP bloklara derler çünkü soruna neden olabilir ... Ben ağır yük bir sitede bir Amazon AWS sunucusu ile bu sorunu yaşadım. Sorun yaşamaya devam ederseniz / var / cache / eaccelerator içindeki eaccelerator önbelleğini silerek Inodes'u boşaltın.

rm -rf /var/cache/eaccelerator/*

(veya önbellek yönünüz ne olursa olsun)

Son zamanlarda benzer bir sorunla karşılaştık, Bir işlemin silinen bir dosyaya başvurması durumunda, Inode serbest bırakılmayacaktır, bu yüzden lsof / öğesini kontrol etmeniz ve işlemi öldürmeniz / yeniden başlatmanız inode'ları serbest bırakacaktır.

Burada yanılıyorsam düzelt.

Daha önce de belirtildiği gibi, çok sayıda küçük dosya varsa, dosya sistemi inode bitebilir. Burada çoğu dosya içeren dizinleri bulmak için bazı araçlar sağladım .

Geç cevap: Benim durumumda, oturum dosyalarımın altındaydı

/var/lib/php/sessions

Inodes kullanıyorlardı.
Hatta silme işlemini tetiklemek için crontab'ımı açamadım veya yeni bir dizin yapamadım. PHP kullandığımdan beri , örnek 1'deki kodu kopyaladığım ve kodun bu bölümünü yürütmek için bir cronjob ayarladığım bu kılavuzumuz var .

<?php
// Note: This script should be executed by the same user of web server 
process.

// Need active session to initialize session data storage access.
session_start();

// Executes GC immediately
session_gc();

// Clean up session ID created by session_gc()
session_destroy();
?>

Eğer crontab'ımı nasıl açabileceğimi merak ediyorsanız, o zaman bazı oturumları CLI aracılığıyla manuel olarak sildim.

Bu yardımcı olur umarım!

bu bilgiyi görebiliyordun

for i in /var/run/*;do echo -n "$i "; find $i| wc -l;done | column -t

Bu soruya şimdiye kadar birçok yanıt geldi ve yukarıdakilerin hepsi somut görünüyor. Ben statgiderken kullanarak güvenli olacağını düşünüyorum , ama OS bağlı olarak, bazı inode hataları size sürünen alabilirsiniz. Bu nedenle, herhangi bir taşma sorununu önlemek için kendi statarama işlevinizi uygulamak 64bitoldukça uyumlu görünmektedir.

Bağlantı istasyonu kullanıyorsanız, tüm görüntüleri kaldırın. Birçok yer kullandılar ....

Tüm kapsayıcıları durdur

docker stop $(docker ps -a -q)

Tüm kapsayıcıları sil

docker rm $(docker ps -a -q)

Tüm resimleri sil

docker rmi $(docker images -q)

Bana çalışıyor