Inode Limiti Doldu: Hangi Klasör Şişirdi ve Nasıl Temizlenir

cPanel'in sol kenar çubuğuna bakıyorsunuz: Disk Kullanımı 8,4 GB / 25 GB yazıyor, yani alanın üçte biri bile dolmamış. Hemen altındaki satır ise kıpkırmızı: Dosya Kullanımı 250.000 / 250.000. Aynı anda WordPress "eklenti güncellenemedi" diyor, FTP'den yüklediğiniz dosya karşı tarafta 0 bayt olarak duruyor, birkaç müşteriniz gönderdikleri e-postanın geri döndüğünü söylüyor. Sunucuda yer var ama hiçbir şey yazılamıyor.

Bu tablonun sebebi disk değil, inode limitidir. Dosya sisteminde her dosya, her klasör ve her sembolik bağlantı bir inode kaydı tüketir. Bu kaydın boyutu, dosyanın 2 baytlık bir .htaccess mi yoksa 4 GB'lık bir video mu olduğuna bakmaz. Yani 400.000 tane 1 KB'lık önbellek parçası, disk tarafında sadece 400 MB görünürken inode tarafında hesabınızı tamamen bitirir. Kavramın kendisini ayrıntılı okumak isterseniz disk kotası ve inode limiti yazısı iyi bir başlangıç; bu rehber ise tanımı geçip doğrudan teşhise iniyor.

Aşağıda önce limitin gerçekten inode olduğunu doğrulayacağız, sonra dosya sayısını klasör bazında çıkarıp suçluyu bulacağız. Ardından pratikte karşımıza çıkan beş yığını sırayla ele alıp her biri için güvenli temizlik yöntemini vereceğiz. Son bölümde de "sildim ama sayı düşmedi" sorusunun cevabı var.

Gerçekten Inode mu Doldu? Önce Bunu Doğrulayın#

Yanlış limiti kovalamak en çok vakit kaybettiren hatadır. Üç hızlı kontrol yeterli.

1. cPanel istatistik çubuğu. Sol kenardaki listede "Dosya Kullanımı" (bazı temalarda "File Usage" veya "Inode") satırını arayın. Sayı limite değmişse teşhis tamamdır. Bu satır bazı hosting firmalarında gizlidir; görünmüyorsa aşağıdaki iki yöntemle ilerleyin.

2. SSH'ten kota sorgulama. Hesabınızda kabuk erişimi varsa en kesin cevabı quota verir:

quota -s

Çıktıdaki files sütunu kullandığınız inode sayısını, limit sütunu ise tavanınızı gösterir. blocks sütunu disk alanıdır; ikisini karıştırmayın. Kabuk erişimini nasıl açacağınızı bilmiyorsanız cPanel SSH erişimi yazısına bakabilirsiniz.

3. Toplam dosya sayısını saymak. Kota bilgisi hiç gelmiyorsa ev dizininizi doğrudan sayın:

find ~ -xdev | wc -l

-xdev bayrağı, farklı bir dosya sistemine bağlanmış klasörlere geçmeyi engeller; sanal dizinler yüzünden sayı şişmez.

Bu arada df -i komutunu görürseniz dikkatli olun: paylaşımlı bir hostingte o komut sizin kotanızı değil, tüm sunucunun dosya sistemi durumunu gösterir. Kendi VDS'inizde anlamlıdır, paylaşımlı pakette yanıltıcıdır.

Belirtileri sebeplerle eşleştirmek de teşhisi hızlandırır:

Alttaki iki satır inode ile ilgisizdir; onları paylaşımlı hosting kaynak limitleri tarafında aramak gerekir.

Hangi Klasör Şişirdi: Dosya Sayısını Klasör Bazında Çıkarmak#

Teşhisin can alıcı noktası burası. Disk boyutuna bakan araçlar sizi yanlış yere götürür: 3 GB'lık bir yedek arşivi tek bir inode tüketirken, 40 MB'lık bir önbellek klasörü 90.000 inode yiyor olabilir. O yüzden boyut değil, adet saymamız lazım.

Modern sunucularda en pratik komut du aracının --inodes bayrağıdır:

# Ev dizininin ilk seviyesindeki klasörleri dosya sayısına göre sırala
du --inodes -d 1 ~ | sort -rn | head -20

Çıktı size doğrudan "en çok dosya barındıran ilk 20 klasör" listesini verir. Şişkin klasörü bulduktan sonra aynı komutu bir seviye derine indirerek daralın:

du --inodes -d 2 ~/public_html/wp-content | sort -rn | head -20

du: unrecognized option '--inodes' hatası alırsanız sunucudaki coreutils sürümü eskidir. Bu durumda find ile aynı sonucu üretebilirsiniz:

# Bulunduğunuz dizindeki her alt klasör için toplam dosya sayısı
for d in */; do echo "$(find "$d" -xdev | wc -l) $d"; done | sort -rn | head -20

Tek bir klasörün toplamını merak ediyorsanız:

find ~/mail -xdev | wc -l
find ~/public_html/wp-content/uploads -xdev -type f | wc -l

Küçük dosyaların nerede biriktiğini görmek de işe yarar; çünkü inode sorununu yaratan neredeyse her zaman "çok sayıda küçük dosya"dır:

# 10 KB'tan küçük dosyaları en çok barındıran dizinler
find ~ -xdev -type f -size -10k -printf '%h\n' | sort | uniq -c | sort -rn | head -20

SSH erişiminiz yoksa cPanel'in Disk Kullanımı ekranı da yol gösterir, ancak orada gördüğünüz sayılar boyut cinsindendir. Yine de "beklemediğim bir klasör listede" tespitini yapmanızı sağlar; detaylı kullanımı cPanel disk kullanımı yazısında anlatılıyor. Dosya Yöneticisi'nde bir klasöre girip sağ alttaki öğe sayısına bakmak da kaba bir ölçüm verir.

Bu noktada elinizde bir şüpheli listesi olacak. Aşağıdaki beş yığın, on vakanın dokuzunu açıklıyor.

Suçlu 1: PHP Session Dosyaları#

PHP, oturum verisini varsayılan olarak diske yazar ve her ziyaretçi için ayrı bir dosya oluşturur. cPanel kurulumlarında bu dosyalar genellikle ~/tmp altında sess_ önekiyle durur. Çöp toplama mekanizması bazı yapılandırmalarda ya kapalıdır ya da olasılık değeri sıfıra çekilmiştir; o zaman aylardır silinmeyen milyonlarca oturum dosyası birikir. Bot trafiği alan bir sitede bu yığın haftada 100.000 dosyayı bulabilir, çünkü her bot isteği yeni bir oturum açar.

Önce ölçün:

find ~/tmp -maxdepth 1 -type f -name 'sess_*' | wc -l

Sayı on binlerdeyse suçluyu buldunuz. Temizlerken aktif oturumlara dokunmayın, yoksa o anda giriş yapmış tüm kullanıcılar dışarı atılır. Sadece belirli bir yaştan eskileri silin:

# İki günden eski oturum dosyalarını sil
find ~/tmp -maxdepth 1 -type f -name 'sess_*' -mtime +2 -delete

Oturum yolunuzun gerçekten ~/tmp olduğundan emin olmak için cPanel'de MultiPHP INI Editor'ü açıp session.save_path satırına bakın. Kalıcı çözüm iki adımlıdır: session.gc_maxlifetime değerini makul bir seviyede tutmak (örneğin 1440 saniye) ve yukarıdaki silme komutunu günlük bir cron görevine bağlamak.

# Cron: her gece 04:10'da eski oturumları temizle
10 4 * * * find /home/kullanici/tmp -maxdepth 1 -type f -name 'sess_*' -mtime +2 -delete

WooCommerce veya benzeri bir eklenti kullanıyorsanız oturumları veritabanında saklama seçeneği varsa onu tercih edin; dosya sistemi yükü tamamen kalkar.

Suçlu 2: Eski E-postalar, Spam ve .Trash Klasörleri#

cPanel Maildir formatı kullanır ve bu formatta her e-posta mesajı ayrı bir dosyadır. 40.000 mesajlı bir posta kutusu, ekleri hiç saymadan 40.000 inode demektir. Bir hesapta üç kullanıcı, her birinde arşiv, çöp kutusu ve spam klasörleri olduğunda toplam kolayca yüz binleri bulur.

Önce mail tarafının payını ölçün:

find ~/mail -xdev -type f | wc -l
du --inodes -d 3 ~/mail | sort -rn | head -20

En sık şişen üç yer şunlardır: hiç boşaltılmamış .Trash klasörü, filtrelenmiş ama silinmeyen .spam klasörü ve otomatik betiklerin (cron çıktıları, form bildirimleri) yerel bir adrese yıllarca yazdığı gelen kutusu.

En güvenli temizlik yolu cPanel'in E-posta Disk Kullanımı ekranıdır: hesap ve klasör bazında listeyi görüp "belirli tarihten eski mesajları sil" seçeneğini kullanabilirsiniz. Bu ekran IMAP indekslerini de tutarlı bırakır. SSH tarafında çalışacaksanız hedefi dar tutun:

# Çöp kutularındaki 30 günden eski mesajlar
find ~/mail -path '*/.Trash/*' -type f -mtime +30 -delete

# Spam klasörlerindeki 14 günden eski mesajlar
find ~/mail -path '*/.spam/*' -type f -mtime +14 -delete

Silme işleminden sonra webmail'de klasörü yenilemek indeksin güncellenmesini sağlar. Kalıcı çözüm, e-posta hesaplarına makul kota tanımlamak ve müşteri tarafında POP3 kullanılıyorsa "sunucudan sil" seçeneğini açık tutmaktır. Yedek almak istiyorsanız mesajları hesapta bırakmak yerine dışarı taşıyın; cPanel yedekleme yöntemleri bunun için yeterli.

Suçlu 3: Eklenti Önbellek ve Görsel Boyut Klasörleri#

WordPress tarafındaki en sinsi yığın budur; çünkü tamamen "normal" çalışmanın bir yan ürünüdür.

Önbellek eklentileri her sayfa için ayrı HTML, CSS ve JS dosyası üretir. Ürün filtreleri veya sayfalama yüzünden URL çeşitliliği yüksek bir mağazada bu sayı kolayca 200.000'i geçer. Tipik adresler:

İkinci kaynak medya kütüphanesidir. WordPress yüklediğiniz her görselden tema ve eklentilerin tanımladığı her boyut için ayrı bir dosya üretir. Aktif bir temada bu sayı 12–15'i bulur; 3.000 ürün görseli, 40.000 civarı dosya demektir. Ölçmek için:

du --inodes -d 1 ~/public_html/wp-content | sort -rn | head
find ~/public_html/wp-content/uploads -xdev -type f | wc -l

Önbelleği temizlerken doğru sıra şudur: önce eklentinin kendi arayüzünden "önbelleği temizle" deyin. Doğrudan rm -rf ile klasörü uçurmak, bazı eklentilerin beklediği index.php veya yapılandırma dosyalarını da götürür ve site 500 hatası verir. Eklenti temizliği yaptıktan sonra hâlâ artık kalmışsa, klasörün içindekileri değil alt klasörlerini hedefleyin:

find ~/public_html/wp-content/cache -mindepth 1 -maxdepth 1 -type d -exec rm -rf {} +

Görsel boyutları için kalıcı çözüm, temanızın kullanmadığı boyutları add_image_size tanımlarından çıkarmak veya bir "unused image sizes" eklentisiyle üretimi durdurmaktır. Geçmişte üretilmiş fazlalıkları silmek risklidir; önce yedek alın. Hangi eklentinin ne kadar dosya ürettiğini araştırırken hangi eklenti siteyi yavaşlatıyor yazısındaki eleme yöntemi de işinize yarar.

Suçlu 4: Softaculous ve Eklenti Yedekleri#

Yedek almak iyidir; yedeği aynı hesabın içinde biriktirmek inode kotasını bitirir. İki farklı davranış var ve ikincisi çok daha tehlikeli.

Sıkıştırılmış tek dosyalık yedekler (.tar.gz, .zip) disk alanı yer ama inode tarafında bir tanedir. Buna karşılık klasör olarak duran açık yedekler sitenin tüm dosya ağacını ikinci kez kopyalar; yani inode kullanımınızı bir gecede ikiye katlar. Üç yedek tutuyorsanız dörde katlar.

Kontrol edilecek yerler:

du --inodes -d 1 ~ | sort -rn | head -20
ls -lh ~/softaculous_backups 2>/dev/null
du --inodes -d 1 ~/public_html/wp-content | sort -rn | head

En sık rastlananlar: Softaculous'un ~/softaculous_backups klasörü, UpdraftPlus'ın wp-content/updraft klasörü, All-in-One WP Migration'ın wp-content/ai1wm-backups klasörü, Duplicator'ın wp-snapshots klasörü ve elle açılıp unutulmuş bir public_html/eski-site kopyası.

Yapılacak iş nettir: indirin, kontrol edin, hesaptan silin. Yedek eklentisinin ayarlarında saklanan kopya sayısını 1'e düşürün ve hedefi uzak bir depoya (harici disk, ayrı bir depolama hesabı) alın. Aynı sunucuda duran yedek zaten gerçek bir yedek değildir; sunucu kaybedildiğinde o da gider.

Bu arada "site kopyası" ararken sadece açık klasörlere değil, wp-content altındaki plugins.old, themes-yedek gibi isimlere de bakın. Nokta ile başlayan gizli klasörleri de listeye katmayı unutmayın:

ls -la ~ | head -40

Suçlu 5: Sonsuz Büyüyen Log Dosyaları#

Log dosyaları genelde inode değil disk sorunudur; ama iki durumda inode'a dönüşür.

Birincisi, PHP'nin log_errors açıkken error_log yolunun tanımlı olmaması. Bu durumda PHP, hatanın oluştuğu her klasöre ayrı bir error_log dosyası yazar. 800 klasörlü bir sitede 800 ayrı dosya demektir. Bulmak için:

find ~ -xdev -type f -name 'error_log' | wc -l
find ~ -xdev -type f -name 'error_log' -size +1M -exec ls -lh {} \;

Silmeden önce içeriğine bakın; çözülmemiş bir hatanın izini taşıyor olabilir. Ne dediklerini yorumlamak için cPanel hata kayıtları yazısı yardımcı olur. Kontrolden sonra:

find ~ -xdev -type f -name 'error_log' -delete

İkincisi, "her gün / her kaynak için ayrı dosya" mantığıyla yazan uygulama günlükleridir: WooCommerce'in wc-logs klasörü, güvenlik eklentilerinin tarama kayıtları, e-posta eklentilerinin gönderim geçmişi. Bunlar günde onlarca dosya üretir ve hiçbir zaman kendiliğinden temizlenmez.

find ~/public_html/wp-content/uploads/wc-logs -type f -mtime +14 -delete

Kendi sunucunuzu yönetiyorsanız bu işi elle yapmak yerine sisteme devredin; logrotate ile log yönetimi tam olarak bu iş için var. WordPress tarafında ise geliştirme bittiğinde WP_DEBUG_LOG değerini kapatmayı unutmayın; açık kalmış bir hata ayıklama günlüğü aylar içinde gigabaytlara ulaşır.

Sildim Ama Sayı Düşmedi: İki Klasik Tuzak#

Temizlik sonrası cPanel'deki rakamın aynı kalması genelde iki nedenden olur.

1. Dosya Yöneticisi'nin çöp kutusu. cPanel Dosya Yöneticisi'nde "Sil" dediğinizde dosyalar varsayılan olarak ev dizininizdeki .trash klasörüne taşınır. Taşınan dosya hâlâ hesabınızdadır; inode'u da hâlâ tüketir. Silme penceresindeki "Dosyaları çöp kutusuna atmadan kalıcı olarak sil" kutusunu işaretlemediyseniz çöp kutusunu boşaltmanız gerekir:

du --inodes -d 1 ~/.trash 2>/dev/null
rm -rf ~/.trash/*

Aynı davranışın arayüz tarafındaki ayrıntıları cPanel dosya yöneticisi yazısında anlatılıyor.

2. Kota önbelleği. cPanel kota rakamlarını gerçek zamanlı hesaplamaz; belirli aralıklarla yeniden tarar. Silme işleminden sonra panelde eski rakamı birkaç saat görebilirsiniz. Gerçek durumu görmek için quota -s veya find ~ -xdev | wc -l komutuna güvenin. Panel rakamı bir günden uzun süre düzelmiyorsa hosting sağlayıcınızdan kota yeniden hesaplaması isteyin; bu, sunucu tarafında root yetkisi gerektiren bir işlemdir.

Bir Daha Dolmaması İçin Kalıcı Düzen#

Temizlik tek seferlik bir iş; asıl mesele aynı yığının üç ay sonra geri gelmesini engellemek. Aşağıdaki beş madde bunu sağlar:

1. Ölçümü otomatikleştirin. Haftalık bir cron görevi, en şişkin klasörleri bir dosyaya yazsın. Sorun büyümeden fark edilir.

   0 6 * * 1 du --inodes -d 2 /home/kullanici | sort -rn | head -25 > /home/kullanici/inode-rapor.txt
   

2. Oturum ve önbellek için yaş sınırı koyun. Yukarıdaki find ... -mtime +N -delete kalıplarını cron'a bağlayın.

3. Yedekleri hesabın dışına taşıyın. Aynı sunucudaki yedek hem inode yer hem gerçek koruma sağlamaz.

4. E-postalara kota tanımlayın. Sınırsız posta kutusu, sınırlı inode ile birlikte çalışmaz.

5. Gereksiz görsel boyutlarını kapatın. Yeni yüklenen her görselin kaç dosya ürettiğini bir kez ölçün; sayı 8'in üzerindeyse temanızı gözden geçirin.

Bu düzeni kurduktan sonra hâlâ limite dayanıyorsanız sorun bakımsızlık değil, ölçek olabilir. 250.000 inode'la çalışan bir mağazanın ürün sayısı ve trafiği belirli bir noktayı geçtiğinde tek çare limiti yükseltmek veya kendi kaynak sınırlarınızı belirleyebileceğiniz bir sunucuya geçmektir. Bu kararı vermeden önce en az bir kez tam temizlik yapıp gerçek taban sayınızı görün; genelde 250.000'lik limitin altında rahatça yaşanabilecek bir sitede 180.000 inode'un çöp olduğu ortaya çıkar.

Sıkça Sorulan Sorular#

Inode limiti dolduğunda sitem tamamen kapanır mı?#

Genellikle hayır. Site okunmaya devam eder, ziyaretçiler sayfaları görebilir. Bozulan şey yazma işlemleridir: yeni dosya oluşturulamaz, önbellek yazılamaz, oturum açılamaz, e-posta teslim edilemez, eklenti ve tema güncellemeleri başarısız olur. Önbellek yazamayan bir site belirgin şekilde yavaşlar ve bir süre sonra veritabanına yazan işlemler de hata vermeye başlayabilir.

Dosyaları sildim ama inode sayım düşmedi, neden?#

İki olası neden var. Birincisi cPanel Dosya Yöneticisi'nden silinen dosyaların ev dizinindeki gizli çöp kutusuna taşınmış olması; taşınan dosya hâlâ inode tüketir, çöp kutusunu boşaltmanız gerekir. İkincisi cPanel'in kota rakamlarını önbellekten göstermesi. Gerçek durumu görmek için SSH'ten kota sorgusu çalıştırın; panel rakamı birkaç saat içinde kendiliğinden güncellenir.

Büyük dosyalar mı yoksa küçük dosyalar mı daha çok inode harcar?#

Dosya boyutunun inode tüketimiyle hiçbir ilgisi yoktur. 4 GB'lık tek bir arşiv de, 12 baytlık boş bir metin dosyası da bir inode harcar. Bu yüzden inode sorunu yaşayan hesaplarda suçlu neredeyse her zaman çok sayıda küçük dosyadır: oturum kayıtları, önbellek parçaları, e-posta mesajları ve görsel küçük resimleri. Disk yüzdesine bakarak inode sorununu teşhis edemezsiniz.

E-postalarımı silmek inode kullanımını gerçekten düşürür mü?#

Evet, çoğu zaman en büyük tek kazanç oradan gelir. cPanel her e-posta mesajını diskte ayrı bir dosya olarak saklar, dolayısıyla 60.000 mesajlık bir posta kutusu 60.000 inode demektir. Özellikle hiç boşaltılmamış çöp kutusu ve spam klasörleri kontrol edilmelidir. Silme işlemini cPanel'in e-posta disk kullanımı ekranından yapmak, IMAP indekslerinin tutarlı kalması açısından en güvenli yoldur.

node_modules veya vendor klasörleri inode kotamı etkiler mi?#

Ciddi biçimde etkiler. Tek bir node_modules klasörü projeye göre 30.000 ile 200.000 arasında dosya barındırabilir; Composer'ın vendor klasörü de on binlerce dosyaya ulaşır. Bu klasörler üretim sunucusunda genellikle gereksizdir. Derleme işlemini kendi bilgisayarınızda veya bir derleme ortamında yapıp sunucuya sadece çıktı dosyalarını yükleyin. Zorunlu olarak sunucuda kalması gerekiyorsa geliştirme bağımlılıklarını kurmayın.

Inode limitim yükseltilebilir mi?#

Çoğu sağlayıcı paket yükseltmesiyle limiti artırır, bazıları ek ücretle mevcut pakette de yükseltir. Ancak yükseltmeden önce mutlaka bir temizlik turu yapın: pratikte hesapların büyük bölümünde kullanılan inode'un yarıdan fazlası eski oturum dosyaları, boşaltılmamış çöp kutuları ve unutulmuş yedeklerden oluşur. Temizlik sonrası gerçek taban sayınızı ölçün, büyüme hızınızı tahmin edin ve kararı ona göre verin.