Dosya Sistemi Hataları: fsck ile Adım Adım Onarım
Sistem yöneticiliğinde en sinir bozucu anlardan biri, bir sunucunun beklenmedik şekilde kapanması veya elektrik kesilmesi sonrası yeniden başlatıldığında dosya sistemi hatalarıyla karşılaşmaktır. Ekran bir sürü kırmızı mesajla dolarken içinizde “acaba ne kaybettim?” sorusu çakmaya başlar. İşte tam bu noktada fsck (File System Consistency Check) devreye girer ve çoğu zaman sizi kurtarır.
fsck Nedir ve Ne Zaman Kullanılır?
fsck, Linux sistemlerde dosya sistemi tutarlılığını kontrol eden ve bulunan hataları onaran temel bir araçtır. Ext2, ext3, ext4, XFS, Btrfs gibi farklı dosya sistemleri için özelleşmiş versiyonları vardır. Aslında fsck bir wrapper (sarmalayıcı) programdır; arka planda dosya sistemine göre e2fsck, xfs_repair veya benzeri araçları çalıştırır.
Ne zaman kullanmalısınız?
- Beklenmedik sistem kapanmalarından sonra
- “Input/output error” mesajları alındığında
- Sistem boot sırasında fsck hataları görüldüğünde
dmesgçıktısında disk hatası uyarıları belirdiğinde- Bir partisyonu mount etmeye çalışırken hata aldığınızda
- Periyodik bakım sırasında (özellikle kritik sunucularda)
Önemli kural: fsck‘yi asla mount edilmiş bir dosya sistemi üzerinde çalıştırmayın. Bu, veri kaybına veya daha büyük hasara yol açabilir.
Temel fsck Kullanımı
En basit kullanım şekliyle başlayalım:
# Dosya sistemini kontrol et (sadece oku, düzeltme yapma)
fsck /dev/sda1
# Tüm partition'ları kontrol et
fsck -A
# Belirli bir dosya sistemi tipi için
fsck -t ext4 /dev/sda1Parametreleri açıklayalım:
- -A: /etc/fstab’daki tüm dosya sistemlerini kontrol eder
- -t: Dosya sistemi tipini belirtir
- -n: Salt okunur mod, hiçbir değişiklik yapmaz
- -y: Tüm sorulara otomatik olarak “yes” yanıtı verir
- -f: Temiz görünse bile dosya sistemini zorla kontrol eder
- -v: Verbose (ayrıntılı) çıktı verir
- -C: İlerleme çubuğu gösterir (interaktif kullanım için)
- -r: Her hatada onay ister (interaktif mod)
Boot Sırasında fsck Çalıştırma
Çoğu gerçek dünya senaryosunda, sistem boot sırasında otomatik olarak fsck devreye girer. Ama bazen sistemi rescue mode’a alıp manuel müdahale etmeniz gerekir.
# GRUB'dan rescue moduna geçiş için kernel parametresi ekleyin:
# linux /boot/vmlinuz-... root=/dev/sda1 ro single
# Rescue modda root partition'ı readonly mount edilir
# Önce unmount veya remount edin
mount -o remount,ro /
# Şimdi fsck çalıştırın
fsck -f /dev/sda1
# Tamamlandıktan sonra reboot edin
rebootGerçek Dünya Senaryosu 1: Üretim ortamındaki bir web sunucusu, UPS arızası nedeniyle aniden kapandı. Yeniden başlatmada sistem “emergency mode”a düştü ve şu mesajı gördünüz:
/dev/sda2: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.Bu durumda önce root shell’e geçip dosya sistemini kontrol etmeniz gerekir:
# Emergency mode'da root shell'e geçtiniz
# Önce hangi partition sorunlu öğrenin
dmesg | grep -i "error|fsck|ext4"
# Partition'ı kontrol et
fsck -f -y /dev/sda2
# Çıktıyı kaydetmek için
fsck -f -y /dev/sda2 2>&1 | tee /tmp/fsck_output.txte2fsck ile Detaylı Ext4 Onarımı
Ext4 dosya sistemi kullanan sistemlerde (ki bu Ubuntu, Debian, RHEL ve türevlerinin büyük çoğunluğudur) e2fsck doğrudan kullanmak size daha fazla kontrol sağlar.
# Temel ext4 kontrolü
e2fsck -f /dev/sda1
# Otomatik onarım modu (dikkatli kullanın)
e2fsck -p /dev/sda1
# Tüm sorulara yes diyerek agresif onarım
e2fsck -y /dev/sda1
# Detaylı istatistiklerle birlikte
e2fsck -f -v /dev/sda1Tipik bir e2fsck çıktısı şöyle görünür:
e2fsck 1.46.5 (30-Dec-2021)
/dev/sda1: recovering journal
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda1: 245678/1310720 files (0.2% non-contiguous), 2847561/5242880 blocksBuradaki 5 pass (geçiş) şunları kontrol eder:
- Pass 1: Inode’ları, blokları ve boyutları kontrol eder
- Pass 2: Dizin yapısını kontrol eder
- Pass 3: Dizin bağlantılarını kontrol eder
- Pass 4: Referans sayılarını kontrol eder
- Pass 5: Grup özet bilgilerini kontrol eder
XFS Dosya Sistemi Onarımı
RHEL 7+ ve CentOS 7+ sistemlerde varsayılan dosya sistemi XFS’e geçmiştir. XFS için xfs_repair kullanılır ve fsck komutu zaten arka planda bunu çağırır.
# XFS partition kontrolü
xfs_repair /dev/sda1
# Salt okunur kontrol (onarım yapmaz)
xfs_repair -n /dev/sda1
# Log (journal) temizleyerek onarım
# DİKKAT: Veri kaybı riski var, son çare olarak kullanın
xfs_repair -L /dev/sda1Gerçek Dünya Senaryosu 2: Bir CentOS 8 sunucusunda şu hatayla karşılaştınız:
XFS: Metadata I/O Errorİlk yapmanız gereken journal’ı kontrol etmektir:
# Önce journal durumunu kontrol et
xfs_logprint /dev/sda2
# Eğer log temizlenmesi gerekiyorsa
umount /dev/sda2
xfs_repair -v /dev/sda2
# Detaylı çıktı için
xfs_repair -v -v /dev/sda2 2>&1 | tee xfs_repair_log.txtLost+Found Klasörü ve Orphan Inode’lar
fsck onarım sırasında, hangi dizine ait olduğunu belirleyemediği dosyaları /lost+found klasörüne taşır. Bu durum özellikle beklenmedik kapanmalarda sık görülür.
# Lost+found içeriğini incele
ls -la /lost+found/
# Dosyaları tipine göre incele
file /lost+found/*
# Tarih damgasına göre sırala
ls -lt /lost+found/
# Metin dosyalarının içeriğini incele
for f in /lost+found/*; do
echo "=== $f ==="
file "$f"
if file "$f" | grep -q "text"; then
head -5 "$f"
fi
done/lost+found içindeki dosyaların isimlerini kaybetmiş olabilirsiniz, sadece inode numaraları görünür. Bu dosyaları içeriklerine bakarak ne olduklarını anlamaya çalışabilirsiniz. Özellikle web sunucularında log dosyaları veya konfigürasyon dosyaları burada çıkabilir.
Sistem Çalışırken Sorun Tespiti
Bazen sistemi kapatmadan önce sorunu tespit etmeniz gerekir. Bu noktada şu araçları kullanabilirsiniz:
# Dmesg'de disk hatalarını filtrele
dmesg | grep -E "(error|I/O|EXT4|XFS|BTRFS)" | tail -50
# Disk durumunu S.M.A.R.T. ile kontrol et
smartctl -a /dev/sda
smartctl -H /dev/sda # Sadece health check
# Reallocated sector sayısını kontrol et
smartctl -a /dev/sda | grep -i "reallocated|pending|uncorrectable"
# iostat ile disk I/O hatalarını izle
iostat -x 1 10
# /proc/mdstat RAID durumu (eğer RAID kullanıyorsanız)
cat /proc/mdstatKritik: Eğer smartctl çıktısında çok sayıda “Reallocated Sector Count” veya “Pending Sector” görüyorsanız, disk fiziksel olarak bozulmaya başlamıştır. Bu durumda fsck yerine verilerinizi hemen yedeklemeye odaklanın.
Otomatik fsck Zamanlayıcısı Ayarları
Ext4 dosya sistemlerinde, belirli aralıklarla veya belirli sayıda mount sonrasında otomatik fsck tetiklenebilir. Bu ayarları tune2fs ile yönetebilirsiniz:
# Mevcut ayarları görüntüle
tune2fs -l /dev/sda1 | grep -i "mount|check|interval"
# Mount sayısı kontrolünü ayarla (örneğin her 30 mount'ta bir)
tune2fs -c 30 /dev/sda1
# Zaman bazlı kontrol (örneğin her 6 ayda bir)
tune2fs -i 6m /dev/sda1
# Otomatik kontrolü devre dışı bırak (meşgul production sunucular için)
tune2fs -c 0 -i 0 /dev/sda1
# Son kontrol tarihini görüntüle
tune2fs -l /dev/sda1 | grep "Last checked"Production sunucularda otomatik fsck bazen sorun çıkarabilir, çünkü büyük disk bölümlerinde saatler sürebilir ve bakım penceresi dışında çalışabilir. Bu yüzden kritik sistemlerde zaman bazlı kontrolü devre dışı bırakıp, bakım pencerelerinde manuel olarak çalıştırmak daha iyi bir pratiktir.
systemd Sistemlerde fsck
Modern systemd tabanlı dağıtımlarda fsck, systemd-fsck servisi tarafından yönetilir:
# fsck servis durumunu kontrol et
systemctl status [email protected]
# Boot sırasındaki fsck loglarını görüntüle
journalctl -u systemd-fsck* -b
# Bir önceki boot'taki fsck logları
journalctl -u systemd-fsck* -b -1
# fsck'nin ne kadar sürdüğünü görüntüle
systemd-analyze blame | grep fsckGerçek Dünya Senaryosu 3: Ubuntu 22.04 sunucunuz her yeniden başlatmada fsck için uzun süre bekliyordu. Sorun, çok büyük bir ext4 partition’ının her mount’ta kontrol edilmesiydi. Çözüm:
# Kaç kez mount edildiğini kontrol et
tune2fs -l /dev/sdb1 | grep "Mount count"
# Son kontrol tarihini gör
tune2fs -l /dev/sdb1 | grep "Last checked"
# /etc/fstab'da fsck order'ını 0 yap (otomatik kontrolü kapat)
# /dev/sdb1 /data ext4 defaults 0 0
# ^
# Bu 0 yapıldı
# Ardından manuel olarak periyodik kontrol için cron ekle
echo "0 2 * * 0 root /sbin/fsck -f -y /dev/sdb1 >> /var/log/fsck_weekly.log 2>&1" >> /etc/cron.d/fsck-weeklyBtrfs Dosya Sistemi Kontrolü
Modern Linux sistemlerde giderek yaygınlaşan Btrfs’in kendi kontrol mekanizması vardır:
# Btrfs dosya sistemi kontrolü
btrfs check /dev/sda1
# Salt okunur kontrol
btrfs check --readonly /dev/sda1
# Scrub ile veri bütünlüğü kontrolü (mount edilmişken çalışır)
btrfs scrub start /mount/point
btrfs scrub status /mount/point
# Onarım (çok dikkatli kullanın, önce yedek alın)
btrfs check --repair /dev/sda1Önemli not: btrfs check --repair son derece riskli bir komuttur. Btrfs geliştiricileri bile bu komutu kullanmadan önce mutlaka tam yedek almanızı şiddetle tavsiye eder.
fsck Hata Çıkış Kodları
fsck çalıştıktan sonra exit code’unu kontrol etmek otomasyonda çok önemlidir:
fsck -y /dev/sda1
exit_code=$?
case $exit_code in
0) echo "Hata yok, dosya sistemi temiz" ;;
1) echo "Hatalar bulundu ve düzeltildi" ;;
2) echo "Hatalar düzeltildi, yeniden başlatma gerekli" ;;
4) echo "Hatalar düzeltilemedi, manuel müdahale gerekli" ;;
8) echo "Operasyonel hata" ;;
16) echo "Kullanım hatası" ;;
32) echo "fsck kullanıcı tarafından iptal edildi" ;;
128) echo "Paylaşılan kütüphane hatası" ;;
esacBu exit code’ları özellikle otomatik bakım scriptleri yazarken kritik öneme sahiptir. Çıkış kodu 1 veya 2 ise sistem yöneticisine alert gönderilmeli, 4 ise acil müdahale gerekmektedir.
Kapsamlı Onarım Script’i
Gerçek bir production ortamında kullanabileceğiniz, log tutan ve bildirim gönderen bir script:
#!/bin/bash
# disk_health_check.sh - Disk sağlığı kontrol ve onarım scripti
LOG_FILE="/var/log/disk_health_$(date +%Y%m%d_%H%M%S).log"
ALERT_EMAIL="[email protected]"
DEVICE=${1:-"/dev/sda1"}
log() {
echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" | tee -a "$LOG_FILE"
}
log "Disk sağlık kontrolü başlıyor: $DEVICE"
# Önce SMART kontrolü
if command -v smartctl &>/dev/null; then
log "SMART testi çalıştırılıyor..."
smartctl -H "$DEVICE" >> "$LOG_FILE" 2>&1
SMART_STATUS=$?
if [ $SMART_STATUS -ne 0 ]; then
log "UYARI: SMART testi başarısız! Disk fiziksel sorun yaşıyor olabilir."
echo "SMART testi başarısız: $DEVICE" | mail -s "Disk Uyarısı" "$ALERT_EMAIL"
fi
fi
# Partition mount durumunu kontrol et
if mount | grep -q "$DEVICE"; then
log "HATA: $DEVICE hâlâ mount edilmiş! fsck çalıştırılamaz."
exit 1
fi
# fsck çalıştır
log "fsck çalıştırılıyor..."
fsck -f -y "$DEVICE" >> "$LOG_FILE" 2>&1
FSCK_EXIT=$?
log "fsck çıkış kodu: $FSCK_EXIT"
if [ $FSCK_EXIT -ge 4 ]; then
log "KRİTİK: Hatalar düzeltilemedi!"
cat "$LOG_FILE" | mail -s "KRİTİK: Disk Hatası $DEVICE" "$ALERT_EMAIL"
exit $FSCK_EXIT
elif [ $FSCK_EXIT -ge 1 ]; then
log "Hatalar bulundu ve düzeltildi. Yeniden başlatma önerilir."
echo "Disk hatalar düzeltildi: $DEVICE" | mail -s "Disk Onarım Raporu" "$ALERT_EMAIL"
else
log "Dosya sistemi temiz, sorun yok."
fi
log "Kontrol tamamlandı. Log: $LOG_FILE"Önleyici Tedbirler
Dosya sistemi hataları tamamen önlenemez ama sıklığı azaltılabilir:
- Journaling aktif tutun: Ext3, ext4, XFS gibi journaling destekli dosya sistemleri tercih edin. Journaling, beklenmedik kapanmalarda veri tutarlılığını çok daha iyi korur.
- UPS kullanın: Sunucularınızı güç kesintilerine karşı UPS ile koruyun. Disk hatalarının büyük çoğunluğu ani güç kesilmelerinden kaynaklanır.
noatimemount seçeneği: Diskin aşınmasını azaltmak için/etc/fstab‘anoatimeseçeneği ekleyin.- Düzenli yedekleme: fsck her şeyi kurtaramaz. 3-2-1 yedekleme kuralını (3 kopya, 2 farklı medya, 1 offsite) uygulayın.
- Disk sağlığını izleyin:
smartmontoolskurarak otomatik SMART takibini aktif edin:systemctl enable smartd && systemctl start smartd - LVM ve RAID kullanın: Kritik veriler için LVM snapshot veya RAID yapısı kullanmak, olası bir disk arızasında sizi korur.
Sonuç
fsck ve ilgili araçlar, bir Linux sistem yöneticisinin araç kutusunun vazgeçilmez parçalarıdır. Ancak bu araçları akılcı kullanmak gerekir. İlk kural mount edilmiş bir dosya sistemine asla dokunmamak, ikinci kural büyük onarımlar öncesinde mutlaka yedek almaktır. Özellikle e2fsck -y veya xfs_repair -L gibi agresif komutlar, hatalı ya da yanlış partition üzerinde çalıştırıldığında veri kaybına yol açabilir.
Gerçek hayatta çoğu dosya sistemi hatası, doğru araçlar ve metodoloji ile çözülebilir durumdadır. Önemli olan paniklemeden, sistematik şekilde ilerlemektir: önce dmesg ve loglarla sorunu tespit et, SMART ile fiziksel durumu değerlendir, dosya sistemini unmount et, uygun fsck varyantını çalıştır ve çıkış kodunu kontrol et. Bu adımları takip ettiğinizde, gece 3’te size düşen acil müdahalelerin büyük çoğunluğunu başarıyla atlattığınızı göreceksiniz.