Linux'ta Disk Komutları: Alan, inode ve Disk Sağlığı

Sunucu açılıyor, servisler de çalışıyor, ancak bir dosyayı kaydetmek istediğinde yanıt No space left on device oluyor. df -h ile baktığında alanın yüzde 40'ının boş olduğunu görüyorsun. İşte burada sorunun disk alanı değil, inode olduğunu bilmen gerekir. Linux'ta disk komutları tam da bu anlar için vardır: tahmin etmeden hızlı teşhis.

df ve du: Farkı nereden anlarız

İki komut, iki farklı soru. df dosya sistemine "ne kadar yerin var?" diye sorar, du ise dizinlere "ne kadar tükettin?" diye sorar.

df -hT
df -i
du -sh /var/log/*
du -xhd1 / 2>/dev/null | sort -h

-T anahtarı dosya sistemi türünü gösterir (ext4, xfs, overlay). -i kullanılan inode sayısını getirir ve df -h alan gösterdiği halde yazmanın mümkün olmadığı durumda ilk çalıştırman gereken komut tam da budur. du içindeki -x anahtarı dosya sistemi sınırını aşmamasını sağlar; bu olmadan, birden fazla mount'u olan bir sunucuda çıktı anlamsız hale gelir ve dakikalar sürebilir.

Çoğu kişiyi şaşırtan nokta: bir dosyayı silmiş olsan bile bir süreç hâlâ onu açık tutuyorsa, du onu görmez ama alan da serbest bırakılmamıştır. Burada lsof +L1 komutuna başvurup süreci yeniden başlatman gerekir.

inode bitti ama alan boş

Bu hatayı pratikte çok görüyorum, özellikle session veya cache'i çok sayıda küçük dosyayla çalışan sunucularda. Belirtiler tam olarak şunlardır:

• df -h boş alan gösterir.
• df -i IUse% değerinde 100 verir.
• Diske her yazma başarısız olur, hatta touch /tmp/test bile.

Hızlı çözüm, en fazla dosyaya sahip dizini bulmaktır:

for d in /var/*; do echo -n "$d: "; find "$d" -xdev | wc -l; done

Genellikle suçlu /var/lib/php/sessions veya /var/spool/postfix'tir. Bir dizindeki dosya sayısı birkaç yüz bini aşarsa, ls bile yavaşlar ve rm -rf * yerine find ... -delete ile temizlik yapman gerekir.

Bölüm, mount ve fstab

Yeni bir disk eklediğinde, iş sırası önemlidir. Önce lsblk -f ile diskin tanınıp tanınmadığına bak. Çıktı boşsa, sorun Linux'ta değil sanallaştırma katmanındadır. Sonra bölümleme ve format:

parted /dev/sdb mklabel gpt
parted /dev/sdb mkpart primary ext4 0% 100%
mkfs.ext4 -L data /dev/sdb1
mkdir -p /mnt/data
mount /dev/sdb1 /mnt/data

/etc/fstab içine asla /dev/sdb1 adını yazma. Disklerin yer değiştirdiği bir sunucuda bu, sunucunun bir sonraki boot'ta emergency mode'a girmesine neden olur. UUID kullan:

UUID=8f3c1a2e-... /mnt/data ext4 defaults,noatime 0 2

noatime seçeneğini ciddiye al. Yoğun trafikli bir sunucuda, erişim zamanı güncellemesini kaldırmak saniyede onlarca IOPS tasarrufu sağlayabilir. Reboot'tan önce her zaman mount -a çalıştır ve findmnt --verify al. Hata verirse, reboot etme.

smartctl ile disk sağlığını kontrol etme

Diskler ölmeden önce haber verir. Sadece dinlemen yeterli:

smartctl -a /dev/sda
smartctl -H /dev/nvme0

Üç alana bak: Reallocated_Sector_Ct, Pending_Sector ve SSD'de Media_Wearout_Indirect. Pending_Sector sıfırın üzerine çıkarsa, diski değiştir; bu sayı geri dönmez. NVMe için nvme smart-log /dev/nvme0 komutu ömür tüketim yüzdesini doğrudan verir.

Kısa bir test de yap: smartctl -t short /dev/sda ve iki dakika sonra smartctl -l selftest /dev/sda. Test vakaların yüzde 90'ında geçse bile bir kez fail verirse, o bir kez yeterlidir.

Burada hata yapıyorlar

En sık gördüğüm hata şudur: biri df -h çalıştırır, / dizininin dolu olduğunu görür ve ardından rm -rf /var/log/* yapar. Sonuç? Loglar silinir, alan boşalır ve iki hafta sonra aynı şey tekrar olur çünkü kimse logrotate'i ayarlamamıştır. Daha kötüsü: MySQL gibi bazı servisler log dizinine bağımlıdır ve bunların silinmesi startup hatasına neden olur.

Belirtisi şudur: temizlikten sonra servis açılmaz ve journalctl -xe içinde bir log dosyası üzerinde permission denied hatası görürsün. Doğru yol, manuel temizlik değil, belirli maxsize ve rotate ile logrotate'i ayarlamaktır.

Hangi aracı seçmeliyiz

Sunucu bulut altyapısındaysa ve disk ağ üzerinden bağlanıyorsa, du sayıları df ile uyuşmayabilir; bu normaldir ve rezerve edilmiş bloklar ile depolama katmanından kaynaklanır. Bu durumda du'ya değil, df'ye güven.

Ağır yük altındaki ve disk I/O'su darboğaz haline gelen sunucular için, donanım yükseltmesiyle ilgili herhangi bir karardan önce yüksek sunucu yükünün nedenini teşhis etme yazısını oku; çoğu zaman sorun diskte değil, bir sorgu veya başıboş bir süreçtedir. Verileri taşımayı düşünüyorsan da scp ve rsync ile dosya transferi doğru yöntemi permission koruma ve resume ile gösterir.

Ve bir gün işletim sistemine erişimi tamamen kaybedersen, sunucuyu yeniden kurma ve rescue moduyla çalışma veri kurtarma yolunu adım adım açıklar. Risk alamayacağın üretim sunucuları için, NVMe diskli ve bölümleme üzerinde tam kontrollü özel sunucu daha mantıklı bir seçimdir; değişken iş yükün varsa bulut sunucu downtime olmadan diski büyütme imkânı verir. İlk kurulum için de Linux hosting basit bir başlangıç noktasıdır.

Sıkça Sorulan Sorular

df boş alan gösterdiği halde neden dosya oluşturamıyorum?

Neredeyse her zaman sorun inode'dur. df -i ile kontrol et; IUse% 100 ise, dosya sistemi boş alan olmasına rağmen yeni dosya oluşturma kapasitesine sahip değildir. Çözüm, çok sayıda küçük dosya içeren dizini bulup bunları temizlemektir.

İkinci durum, dosyanın silinmiş olması ama bir sürecin hâlâ onu açık tutmasıdır. lsof +L1 ile süreci bul ve alanın serbest kalması için yeniden başlat.

du ve df arasındaki fark nedir ve hangisi daha doğrudur?

df dosya sistemi açısından rapor verir, du ise dosyalar ve dizinler açısından. Hiçbiri "daha doğru" değildir, çünkü iki farklı şeyi ölçerler. Diskin dolu olup olmadığına karar vermek için referans df'dir.

Bu ikisi arasındaki sayısal fark genellikle rezerve edilmiş bloklardan, açık tutulan silinmiş dosyalardan ve iç içe dosya sistemlerinden kaynaklanır.

Bir diskin bozulmakta olduğunu nasıl anlarım?

smartctl -a /dev/sda ile ve Reallocated_Sector_Ct ve Pending_Sector alanlarına bakarak. Bu ikisindeki sıfır olmayan her değer ciddi bir işarettir. NVMe'de nvme smart-log komutu ömür tüketim yüzdesini gösterir.

Kısa smartctl -t short testi de faydalıdır, ancak testte hata olmaması diskin kesinlikle sağlıklı olduğu anlamına gelmez.

noatime tüm sunucularda önerilir mi?

Çoğu web ve veritabanı sunucusu için evet. Erişim zamanı güncellemesini kaldırmak, diske yazma yükünü azaltır ve SSD'de kullanım ömrünü uzatır. Tek istisna, tmpwatch veya atime'a dayalı yedekleme betiği gibi bir araç kullanan sunuculardır.

Bu durumda noatime yerine, ikisi arasında denge olan relatime kullan.