Hostingde disk boşken inode kotası yeni dosya yüklemeyi engelleyebilir. Çözüm, gereksiz dosya sayısını azaltmak veya doğru kotayı artırmaktır.
Önce hangi sınırın dolduğunu doğrulayın, ardından dosyaların nerede biriktiğini bulun. Aşağıdaki sıra, Linux tabanlı hosting hesabında rastgele silme yapmadan ilerlemek için hazırlanmıştır.
Varsayımsal örnek: Hesabınızda tek bir büyük arşiv ve binlerce küçük önbellek dosyası bulunduğunu düşünün. Arşivi silmek gigabaytlarca alan açabilir; ancak dosya sayısını çok az azaltır. Sorun inode kotasıysa, yalnız en büyük dosyaları aramak doğru hedefe yöneltmez.
CloudLinux ortamında soft limit belirli bir tolerans süresiyle aşılabilir; hard limit ise yeni kaynak kullanımını engeller. Bir uyarı eşiğini kesin kesinti sınırıyla karıştırmayın ve tolerans süresini bütün sağlayıcılarda aynı kabul etmeyin.
İnode sınırlandırması cPanel’in tek başına sunduğu yerel bir özellik değildir; CloudLinux gibi ek bir katmandan uygulanabilir. Bu nedenle cPanel kullanmanız, kotayı hesabınızdan değiştirebileceğiniz anlamına gelmez.
İki gösterge de sınırın altındaysa, dosya yükleme hatasını yalnız inode sorununa bağlayıp temizliğe başlamayın. Önce hata mesajının gerçekten kota aşımını işaret edip etmediğini değerlendirin.
du --inodes -x --max-depth=1 "$HOME"
Bu komut boyut yerine inode kullanımını raporlar. İlk düzeydeki klasörlerin toplamlarını gösterir ve başka dosya sistemlerine geçmez. Bir klasörün yanındaki sayı, altındaki dizinlerin kullanımını da içerir; ana dizin toplamıyla alt klasörleri yeniden toplayıp çift saymayın.
Bu çıktı silme listesi değildir. Yüksek sayılı klasör, yalnızca daha yakından incelenecek yeri gösterir. Erişim hatası alırsanız raporu eksiksiz kabul etmeyin; sırf sayım yapmak için izinleri değiştirmeyin. SSH yoksa panelinizin sunduğu dosya sayısı veya klasör istatistikleriyle sınırlı kalın.
İnternette önerilen df -i komutu ise dosya sisteminin inode durumunu gösterir. Hesabınıza tanımlanmış hosting kotasını göstermez. Dolayısıyla sunucuda boş inode görünmesi, sizin hesap kotanızın dolmadığını kanıtlamaz. Bu ayrım, GNU’nun dosya sistemi raporlaması ile CloudLinux’un hesap bazlı kota uygulamasının birlikte değerlendirilmesinden çıkar.
Önerilen uygulama sırası şöyledir:
Dosya Yöneticisi içindeki View Trash / Çöp Kutusunu Görüntüle alanını açın. İçeriği gözden geçirip yalnız kaldırılmasını onayladığınız dosyaları kalıcı silin. Empty Trash / Çöp Kutusunu Boşalt bütün kutuyu temizler; incelemeden kullanmayın.
Temizlikten kısa süre sonra aynı klasör yeniden büyüyorsa, yükseltme kararı vermeden önce o klasörü üreten uygulamanın saklama ve temizleme ayarlarını inceleyin. Burada karar ölçütü, daha çok dosyaya gerçekten ihtiyaç duyulması ile gereksiz dosyaların sürekli yeniden üretilmesini birbirinden ayırmaktır.
Önce hangi sınırın dolduğunu doğrulayın, ardından dosyaların nerede biriktiğini bulun. Aşağıdaki sıra, Linux tabanlı hosting hesabında rastgele silme yapmadan ilerlemek için hazırlanmıştır.
Disk alanı ile inode kotasını ayırın
Disk kullanımı dosyaların kapladığı alanı, inode kullanımı ise dosya ve dizinlerle ilişkili sayıyı gösterir. Bu yüzden yeterli boş alanınız bulunurken dosya sayısı sınırına ulaşabilirsiniz. CloudLinux, inode kotalarını hesap veya paket düzeyinde uygulayabilir.Varsayımsal örnek: Hesabınızda tek bir büyük arşiv ve binlerce küçük önbellek dosyası bulunduğunu düşünün. Arşivi silmek gigabaytlarca alan açabilir; ancak dosya sayısını çok az azaltır. Sorun inode kotasıysa, yalnız en büyük dosyaları aramak doğru hedefe yöneltmez.
Önce hesabınızın hangi sınıra ulaştığını doğrulayın
cPanel kullanıyorsanız istatistiklerde şu iki göstergeyi ayrı değerlendirin:- Disk Usage / Disk Kullanımı: Hesabın kullandığı depolama alanını gösterir.
- File Usage / Dosya Kullanımı: Dosya ve dizinlerin inode kullanımını gösterir. Sağlayıcı etkinleştirmediyse bu sayaç görünmeyebilir.
CloudLinux ortamında soft limit belirli bir tolerans süresiyle aşılabilir; hard limit ise yeni kaynak kullanımını engeller. Bir uyarı eşiğini kesin kesinti sınırıyla karıştırmayın ve tolerans süresini bütün sağlayıcılarda aynı kabul etmeyin.
İnode sınırlandırması cPanel’in tek başına sunduğu yerel bir özellik değildir; CloudLinux gibi ek bir katmandan uygulanabilir. Bu nedenle cPanel kullanmanız, kotayı hesabınızdan değiştirebileceğiniz anlamına gelmez.
İki gösterge de sınırın altındaysa, dosya yükleme hatasını yalnız inode sorununa bağlayıp temizliğe başlamayın. Önce hata mesajının gerçekten kota aşımını işaret edip etmediğini değerlendirin.
En büyük klasörü değil, en çok dosya içereni bulun
SSH erişiminiz varsa ve sunucudaki GNU du komutu destekliyorsa, kendi hesabınızın ana dizininde şu salt okunur komutu kullanabilirsiniz:du --inodes -x --max-depth=1 "$HOME"
Bu komut boyut yerine inode kullanımını raporlar. İlk düzeydeki klasörlerin toplamlarını gösterir ve başka dosya sistemlerine geçmez. Bir klasörün yanındaki sayı, altındaki dizinlerin kullanımını da içerir; ana dizin toplamıyla alt klasörleri yeniden toplayıp çift saymayın.
Bu çıktı silme listesi değildir. Yüksek sayılı klasör, yalnızca daha yakından incelenecek yeri gösterir. Erişim hatası alırsanız raporu eksiksiz kabul etmeyin; sırf sayım yapmak için izinleri değiştirmeyin. SSH yoksa panelinizin sunduğu dosya sayısı veya klasör istatistikleriyle sınırlı kalın.
İnternette önerilen df -i komutu ise dosya sisteminin inode durumunu gösterir. Hesabınıza tanımlanmış hosting kotasını göstermez. Dolayısıyla sunucuda boş inode görünmesi, sizin hesap kotanızın dolmadığını kanıtlamaz. Bu ayrım, GNU’nun dosya sistemi raporlaması ile CloudLinux’un hesap bazlı kota uygulamasının birlikte değerlendirilmesinden çıkar.
Temizliği geri dönüşü koruyarak yapın
Önbellekler, kullanılmayan test kopyaları, eski yedekler ve bazı kurulumlarda e-posta dosyaları incelemeye değer alanlardır. Ancak aynı klasörün her sitede gereksiz olduğunu varsaymayın. Sağlayıcı belgelerinde de bu kategoriler inode kullanımını azaltma seçenekleri arasında yer alır.Önerilen uygulama sırası şöyledir:
- Silinecek verinin gerekli kopyasını koruyun. Eski yedeği kaldırmadan önce hosting dışındaki kopyasının indirildiğini ve açılabildiğini doğrulayın. Elinizdeki tek geri dönüş kopyasını silmeyin.
- Önbelleği uygulamanın kendi aracından temizleyin. Adında cache geçen her klasörü elle boşaltmak yerine, ilgili uygulamanın veya eklentinin temizleme işlevini tercih edin.
- Test kopyasını kullanım durumuna göre değerlendirin. Klasörün eski görünmesi yeterli değildir. Bir alt alan adına bağlı olmadığını ve devam eden çalışmada kullanılmadığını doğrulayın.
- E-posta aynı kotaya dahilse posta arayüzünü kullanın. Gereksiz iletileri oradan ayıklayın; sunucudaki posta klasörlerini topluca silmeyin.
- Çalışan site dosyalarını koruyun. Medya, eklenti veya tema klasörlerini yalnız dosya sayıları yüksek diye kaldırmayın.
Silinen dosyalar çöp kutusunda kalmış olabilir
cPanel Dosya Yöneticisi, varsayılan silme işleminde dosyaları hesabın ana klasörüne taşır. Dosyalar hâlâ hesapta bulunduğundan, yalnız çöp kutusuna göndermek kalıcı temizlik değildir.Dosya Yöneticisi içindeki View Trash / Çöp Kutusunu Görüntüle alanını açın. İçeriği gözden geçirip yalnız kaldırılmasını onayladığınız dosyaları kalıcı silin. Empty Trash / Çöp Kutusunu Boşalt bütün kutuyu temizler; incelemeden kullanmayın.
Paket yükseltmeden önce hangi kotanın artacağını kontrol edin
Temizlikten sonra kalan dosyalar gerçekten gerekliyse, daha yüksek inode kotası değerlendirmek anlamlı olabilir. Karşılaştırmayı yalnız disk kapasitesi üzerinden yapmayın: hesapta uygulanan dosya sayısı sınırını ve yeni pakette bu sınırın değişip değişmediğini doğrulayın. CloudLinux’ta inode limitlerinin ayrıca tanımlanabilmesi, daha fazla depolama alanıyla daha yüksek inode kotasının aynı şey olmadığını gösterir.Temizlikten kısa süre sonra aynı klasör yeniden büyüyorsa, yükseltme kararı vermeden önce o klasörü üreten uygulamanın saklama ve temizleme ayarlarını inceleyin. Burada karar ölçütü, daha çok dosyaya gerçekten ihtiyaç duyulması ile gereksiz dosyaların sürekli yeniden üretilmesini birbirinden ayırmaktır.