Linux sunucularda bazen çok ilginç bir durumla karşılaşabilirsiniz:

No space left on device

Hatasını alırsınız ancak diski kontrol ettiğinizde yüzlerce GB, hatta TB seviyesinde boş alan vardır.

Örneğin:

df -h

çıktısı:

Filesystem      Size  Used Avail Use%
/dev/sda1       900G  420G  480G  47%

Yani diskin yalnızca %47'si doludur.

Buna rağmen:

touch test.txt

dediğinizde:

No space left on device

hatası alabilirsiniz.

Böyle bir durumda ilk kontrol edilmesi gereken şeylerden biri inode kullanımıdır.

---

1. Inode nedir?

Linux dosya sistemlerinde her dosya ve dizin için metadata tutulur.

Bu metadata'nın bulunduğu yapıya inode denir.

Basitleştirirsek:

Disk alanı
   ↓
Dosyanın içeriği

Inode
   ↓
Dosyanın metadata bilgileri

Bir inode içerisinde dosyayla ilgili:

• sahiplik

• izinler

• dosya tipi

• boyut

• zaman bilgileri

• veri bloklarının adresleri

gibi bilgiler tutulur.

Önemli nokta:

Bir dosya çok küçük olsa bile bir inode tüketebilir.

Bu nedenle milyonlarca küçük dosya bulunan bir sistemde disk alanı boş kalırken inode'lar tamamen tükenebilir.

---

2. Basit bir örnek

Diyelim ki filesystem'inizde:

1 TB disk

var.

Ve:

400 GB kullanılıyor
600 GB boş

olsun.

Ancak sistemde milyonlarca küçük dosya bulunuyorsa inode'lar tükenebilir.

Örneğin:

10.000.000 adet
1 KB'lık dosya

yaklaşık 10 GB veri kullanabilir.

Fakat:

10 milyon inode

tüketir.

Sonuç:

Disk:
%40 dolu

Inode:
%100 dolu

Bu durumda yeni dosya oluşturamazsınız.

Ve Linux:

No space left on device

hatasını verebilir.

---

3. İlk kontrol: df -h

Öncelikle normal disk kullanımına bakalım:

df -h

Örneğin:

Filesystem      Size  Used Avail Use%
/dev/sda1       900G  420G  480G  47%

Burada disk alanı açısından herhangi bir problem görünmüyor.

Şimdi inode kullanımına bakalım.

---

4. Asıl önemli komut: df -i

Şunu çalıştırın:

df -i

Örneğin:

Filesystem      Inodes   IUsed   IFree IUse% Mounted on
/dev/sda1      50000000 50000000       0  100% /

Burada problem açıkça görülüyor:

IUse% = 100%

Yani disk alanı boş olsa bile filesystem üzerinde yeni inode kalmamış.

Dolayısıyla yeni dosya oluşturulamıyor.

---

5. Disk ve inode arasındaki fark

Kısaca:

df -h

→ Disk alanı ne kadar dolu?

df -i

→ Kaç inode kullanılıyor?

Bu nedenle:

df -h → %50
df -i → %100

gibi bir durum mümkün.

Bu, Linux sunucularda oldukça önemli bir teşhis noktasıdır.

---

6. Peki inode'ları ne tüketiyor?

Şimdi asıl soru burada başlıyor:

Hangi klasörde milyonlarca küçük dosya var?

Bunu bulmamız gerekiyor.

İlk olarak root filesystem altında dizinlerin inode kullanımına bakılabilir.

Örneğin:

du --inodes -x -d 1 / 2>/dev/null | sort -n

Bazı sistemlerde du sürümüne göre --inodes desteği bulunmayabilir.

Alternatif olarak belirli dizinleri tek tek inceleyebilirsiniz.

Örneğin:

find /var -xdev -type f | wc -l

ve:

find /tmp -xdev -type f | wc -l

---

7. /tmp en şüpheli yerlerden biri

Özellikle sunucularda /tmp ve /var/tmp kontrol edilmelidir.

Örneğin:

find /tmp -xdev -type f | wc -l

Sonuç:

1842937

gibi bir sayı çıkıyorsa dikkat edilmelidir.

Yaklaşık:

1.8 milyon dosya

bulunuyor demektir.

Bunların toplam boyutu çok yüksek olmayabilir.

Ancak inode tüketimi ciddi olabilir.

---

8. Gizli dosyalar özellikle önemli

Saldırılarda veya hatalı çalışan uygulamalarda dosyalar bazen:

/tmp/.cache
/tmp/.x
/tmp/.data
/tmp/.tmp
/tmp/.session

gibi gizli isimlerle oluşturulabilir.

Bunun yanında hosting ortamlarında:

/home/user/tmp
/home/user/.cache
/home/user/.local

gibi dizinler de kontrol edilmelidir.

Gizli olması tek başına zararlı olduğu anlamına gelmez.

Ancak inode tükenmesi yaşanıyorsa bu dizinler mutlaka incelenmelidir.

---

9. En fazla dosyanın bulunduğu dizini bulmak

Örneğin /var altında problem olduğunu düşünüyorsanız:

for dir in /var/*; do
    [ -d "$dir" ] && printf "%s " "$dir" && find "$dir" -xdev -type f 2>/dev/null | wc -l
done

Bu şekilde hangi alt dizinde çok sayıda dosya bulunduğunu görebilirsiniz.

Örneğin:

/var/log       1523
/var/cache     28492
/var/tmp       1838291
/var/lib       92832

Burada:

/var/tmp

açık şekilde dikkat çekiyor.

---

10. Hosting sunucularında /home özellikle kontrol edilmeli

cPanel veya benzeri hosting sunucularında inode problemlerinin kaynağı çoğu zaman tek bir müşteri hesabı olabilir.

Örneğin:

/home/user1
/home/user2
/home/user3

hesaplarından biri milyonlarca dosya oluşturmuş olabilir.

Kontrol için:

for dir in /home/*; do
    [ -d "$dir" ] && printf "%s " "$dir" && find "$dir" -xdev -type f 2>/dev/null | wc -l
done

kullanılabilir.

Örneğin:

/home/customer1   18234
/home/customer2   45121
/home/customer3   3948212

gibi bir sonuç görürseniz:

customer3

incelenmelidir.

---

11. “Gizli küçük dosya avı” nasıl yapılır?

Problemli kullanıcı veya klasörü bulduktan sonra daha detaylı inceleme yapılabilir.

Örneğin:

find /home/customer3 -xdev -type f -printf '%h\n' 2>/dev/null | sort | uniq -c | sort -nr | head -50

Bu komut hangi dizinlerde çok sayıda dosya bulunduğunu göstermeye yardımcı olur.

Örneğin:

1850000 /home/customer3/tmp/cache
920000  /home/customer3/public_html/wp-content/cache
310000  /home/customer3/.cache

gibi bir çıktı elde edebilirsiniz.

Artık problemli alan çok daha net görünür.

---

12. WordPress cache klasörleri

WordPress sitelerinde cache sistemleri çok sayıda küçük dosya oluşturabilir.

Örneğin:

wp-content/cache
wp-content/litespeed
wp-content/uploads/cache

gibi klasörler kontrol edilebilir.

Özellikle yanlış yapılandırılmış veya aşırı büyüyen cache sistemleri inode tüketimini ciddi şekilde artırabilir.

Ancak cache klasörünü:

rm -rf

ile körü körüne silmek doğru değildir.

Önce kullanılan cache sisteminin ne olduğunu belirlemek gerekir.

---

13. Session dosyaları

PHP session dosyaları da inode tüketebilir.

Örneğin:

/var/lib/php/sessions

veya sistem yapılandırmasına göre başka bir session dizini kullanılabilir.

Kontrol:

find /var/lib/php/sessions -type f 2>/dev/null | wc -l

Sonuç çok yüksekse session temizleme mekanizması düzgün çalışmıyor olabilir.

---

14. Mail queue da kontrol edilmeli

Mail sunucularında çok fazla küçük dosya oluşması inode tüketimine neden olabilir.

Özellikle:

Exim
Postfix
Maildir

yapılarında milyonlarca küçük mail dosyası bulunabilir.

cPanel/Exim sunucularında:

exim -bpc

ile mail queue içerisindeki mesaj sayısı kontrol edilebilir.

Ancak inode probleminin yalnızca queue sayısından kaynaklandığını varsaymayın.

Maildir yapısında kullanıcı posta kutularındaki binlerce küçük dosya da inode tüketebilir.

---

15. “rm -rf /tmp/*” çözüm mü?

İnternette sık görülen önerilerden biri:

rm -rf /tmp/*

komutudur.

Bunu düşünmeden çalıştırmayın.

Çünkü /tmp içerisinde yalnızca gereksiz dosyalar bulunmaz.

Çalışan uygulamalar tarafından kullanılan geçici dosyalar ve socket'ler de bulunabilir.

Özellikle üretim sunucusunda:

rm -rf /tmp/*

gibi agresif bir temizlik işlemi uygulamadan önce neyin silineceği anlaşılmalıdır.

---

16. Güvenli temizlik nasıl yapılmalı?

Önce eski dosyaları listeleyin.

Örneğin 7 günden eski dosyaları görmek için:

find /tmp -xdev -type f -mtime +7 -ls

Kontrol ettikten sonra uygun olduğuna eminseniz:

find /tmp -xdev -type f -mtime +7 -delete

kullanılabilir.

Ancak production sunucularında bu işlem de uygulamanın çalışma biçimi dikkate alınarak yapılmalıdır.

Daha güvenli yaklaşım:

Önce listele
   ↓
Dosyaların kaynağını belirle
   ↓
Uygulamanın ihtiyacını kontrol et
   ↓
Eski/geçici dosyaları temizle
   ↓
inode kullanımını tekrar kontrol et

---

17. Silinen dosya hâlâ yer kaplıyorsa?

Çok önemli başka bir Linux problemi:

Bir dosyayı sildiniz ama disk alanı geri gelmedi.

Örneğin:

rm /var/log/huge.log

dediniz.

Ama:

df -h

hala aynı değeri gösteriyor.

Bunun sebebi dosyanın bir process tarafından hâlâ açık tutulması olabilir.

Kontrol:

lsof +L1

Örneğin:

apache  1234  user  5w  REG  ... /var/log/huge.log (deleted)

gibi bir çıktı görebilirsiniz.

Burada dosya silinmiş olsa bile process dosyayı açık tuttuğu için disk alanı hemen geri dönmeyebilir.

Bu problem inode tükenmesinden farklıdır, ancak “dosyayı sildim ama alan gelmedi” durumunda mutlaka kontrol edilmelidir.

---

18. Inode probleminin başka bir nedeni: milyonlarca küçük dosya

Özellikle şu tür uygulamalar dikkat edilmesi gereken kaynaklardır:

• Cache sistemleri

• Session sistemleri

• Maildir

• Queue sistemleri

• Log sistemleri

• Backup yazılımları

• Temporary dosyalar

• WordPress eklentileri

• Malware

• PHP shell'leri

• Cron scriptleri

• Uygulama cache'leri

Örneğin bir script yanlışlıkla:

while true
do
    touch /tmp/file_$(date +%s%N)
done

gibi sürekli dosya oluşturuyorsa birkaç saat içerisinde çok ciddi inode tüketebilir.

---

19. Malware ihtimalini unutmayın

Eğer normalde 50-100 bin dosyası olan bir hosting hesabı aniden:

2 milyon
5 milyon
10 milyon

dosyaya ulaştıysa sadece “cache şişmiş” demek doğru olmayabilir.

Özellikle:

/tmp
/var/tmp
/home/user/tmp
/home/user/.cache

gibi alanlarda rastgele isimlendirilmiş çok sayıda küçük dosya bulunuyorsa malware ihtimali değerlendirilmelidir.

Örneğin:

/tmp/.x1a8d
/tmp/.k92jd
/tmp/.cache_9182
/tmp/.data_18273

gibi dosyalar görülmesi tek başına malware kanıtı değildir.

Ancak oluşturulma zamanları, sahibi ve içerikleri incelenmelidir.

---

20. Inode problemi tekrar ediyorsa kök nedeni bulun

Sadece dosyaları silmek geçici çözüm olabilir.

Örneğin:

2 milyon dosya
↓
Temizlendi
↓
inode normale döndü
↓
2 gün sonra
↓
3 milyon dosya

oluyorsa bir şey hâlâ dosya üretmektedir.

Bu durumda:

Cron
PHP
WordPress
Plugin
Cache
Mail
Backup
Malware

kaynaklarından hangisinin dosyaları oluşturduğu bulunmalıdır.

---

21. Pratik teşhis komutları

Inode problemi yaşadığınızda aşağıdaki komutlar oldukça faydalıdır.

Disk kullanımını kontrol et:

df -h

Inode kullanımını kontrol et:

df -i

/tmp dosya sayısını kontrol et:

find /tmp -xdev -type f | wc -l

/var/tmp dosya sayısını kontrol et:

find /var/tmp -xdev -type f | wc -l

/home dosya sayısını kontrol et:

find /home -xdev -type f | wc -l

Problemli dizinleri bul:

du --inodes -x -d 2 / 2>/dev/null | sort -n | tail -30

Silinmiş ancak açık dosyaları bul:

lsof +L1

---

22. Hosting sunucuları için hızlı kontrol

cPanel/WHM sunucusunda:

1. df -h
2. df -i
3. /tmp
4. /var/tmp
5. /home
6. /var/log
7. /var/lib
8. Mail queue / Maildir
9. Cache klasörleri
10. Malware kontrolü

sırasıyla incelenebilir.

Özellikle /home altında tek bir hesabın diğer hesaplardan aşırı farklı inode tüketip tüketmediğine bakmak oldukça faydalıdır.

---

Sonuç

Linux'ta:

No space left on device

hatasını gördüğünüzde doğrudan:

rm

veya:

df -h

ile yetinmeyin.

Öncelikle:

df -h
df -i

çıktılarını karşılaştırın.

Eğer:

Disk kullanımı : %40
Inode kullanımı: %100

gibi bir durum varsa problem disk kapasitesi değil, inode tükenmesidir.

Ardından amaç:

inode'ları ne tüketiyor?
        ↓
hangi filesystem?
        ↓
hangi dizin?
        ↓
hangi kullanıcı?
        ↓
hangi uygulama?
        ↓
neden bu kadar dosya oluşturuyor?

sorusunu cevaplamaktır.

Unutmayın:

Diskte 500 GB boş alan olması, sistemde yeni dosya oluşturabileceğiniz anlamına gelmeyebilir. Filesystem'in inode'ları bittiyse birkaç byte'lık yeni bir dosya bile oluşturulamaz.

Bu yüzden Linux sunucu bakımında yalnızca GB/TB disk kullanımını değil, inode kullanımını da düzenli olarak takip etmek gerekir.