ext4 Dosya Sistemi Hata Onarımı: fsck Kullanımı

Disk sorunları her zaman en kötü zamanda ortaya çıkar. Production sunucusu gece 2’de çökmüş, sistem boot olmuyor ve ekibin sizi arıyor. İşte tam bu noktada fsck aracını ve ext4 dosya sisteminin iç yapısını iyi tanımak hayat kurtarır. Bu yazıda ext4 üzerinde fsck kullanımını, yaygın hata senaryolarını ve gerçek dünya onarım süreçlerini ele alacağız.

ext4 Dosya Sistemi ve Tutarsızlık Problemi

ext4, Linux dünyasının en yaygın dosya sistemlerinden biri. Journaling desteği sayesinde ani güç kesintilerinde bile oldukça dayanıklı. Ama “dayanıklı” demek “bozulmaz” demek değil. Donanım arızaları, I/O hataları, RAM sorunları veya kernel bug’ları sonucunda dosya sistemi tutarsız bir duruma düşebilir.

Journaling mekanizması şunu yapar: Diske yazılacak değişiklikleri önce bir journal alanına kaydeder, işlem tamamlanınca asıl konuma yazar. Sistem aniden kapanırsa journal’daki kayıtlar sayesinde kurtarma yapılabilir. Ancak journal da bir şeyleri kurtaramaz; özellikle fiziksel sektör bozulmaları, süperbloğun (superblock) hasar görmesi veya inode tablolarındaki tutarsızlıklar fsck müdahalesi gerektirir.

fsck Nedir, Ne Zaman Kullanılır?

fsck (filesystem check), dosya sistemi tutarsızlıklarını tespit eden ve onarabildiği durumlarda düzelten bir araçtır. Aslında fsck bir ön yüz (frontend) programdır; ext4 için arka planda e2fsck çalışır.

Kritik kural: fsck’yi hiçbir zaman mount edilmiş bir dosya sistemi üzerinde çalıştırma. Bu, tutarsızlıkları düzeltmek bir yana, daha büyük zarara yol açar. Her zaman unmount et ya da read-only mount et.

Fsck ne zaman gerekir:

Sistem boot sırasında “filesystem errors detected” mesajı veriyorsa
dmesg çıktısında EXT4-fs error satırları görünüyorsa
Dosya kopyalama veya okuma sırasında I/O hataları alınıyorsa
Disk aniden read-only moda geçtiyse
Güç kesintisi veya kernel panic sonrası

Temel fsck Kullanımı

Önce basit bir kontrol çalıştıralım. Sistemin /dev/sdb1 üzerinde mount edilmemiş bir ext4 partition’ınız olduğunu varsayalım:

sudo fsck /dev/sdb1

Bu komut temel bir kontrol yapar ama interaktif modda çalışır, her sorun için soru sorar. Production ortamında bunu istemeyebilirsin.

Sık kullanılan parametreler:

-a: Tüm hataları otomatik onar, soru sorma (güvenli hatalar için) -y: Tüm sorulara otomatik “yes” cevabı ver -n: Sadece kontrol et, hiçbir şeyi değiştirme (dry-run) -f: Dosya sistemi temiz görünse bile zorla kontrol et -v: Verbose mod, detaylı çıktı göster -C: Progress bar göster -t ext4: Dosya sistemi tipini belirt

Otomatik onarım için:

sudo fsck -y /dev/sdb1

Sadece kontrol, değişiklik yok:

sudo fsck -n /dev/sdb1

e2fsck ile Daha Fazla Kontrol

Ext4 için doğrudan e2fsck kullanmak daha fazla seçenek sunar:

sudo e2fsck -f -v /dev/sdb1

Bu komut birkaç geçişte çalışır:

Pass 1: İnode’ları kontrol eder
Pass 2: Dizin yapısını kontrol eder
Pass 3: Dizin bağlantılarını kontrol eder
Pass 4: Referans sayımlarını kontrol eder
Pass 5: Grup özet bilgilerini kontrol eder

Çıktıda her geçişin sonucunu görürsünüz. Hata yoksa “clean” yazar.

# Daha detaylı çıktı için
sudo e2fsck -f -v -C 0 /dev/sdb1

-C 0 parametresi progress bilgisini stdout’a yazar, script içinde kullanışlıdır.

Süperblok Sorunları ve Yedek Süperbloktan Kurtarma

Süperblok, dosya sistemi hakkındaki temel bilgileri (boyut, inode sayısı, blok boyutu gibi) tutar. Bozulursa sistem partition’ı tanıyamaz. Neyse ki ext4, birden fazla yedek süperblok saklar.

Yedek süperblokların konumlarını bulmak için:

sudo dumpe2fs /dev/sdb1 | grep -i "superblock"

Ya da daha hızlı:

sudo mke2fs -n /dev/sdb1

-n parametresi gerçekten format atmaz, sadece süperblok konumlarını hesaplayıp gösterir. Tipik çıktıda şunu görürsünüz:

Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912 ...

Birincil süperblok bozuksa yedekten kurtarma:

sudo e2fsck -b 32768 /dev/sdb1

Eğer bu da çalışmazsa farklı bir yedek dene:

sudo e2fsck -b 98304 /dev/sdb1

Süperblok kurtarma başarılı olursa, e2fsck otomatik olarak birincil süperbloku da onarır.

Boot Sırasında Fsck: Recovery Mode Kullanımı

Sistem hiç boot olmuyorsa recovery mode veya live USB gerekir. GRUB menüsünde “Advanced options” altından recovery mode seçebilirsin.

Recovery mode’da root shell açıldığında sistemin root partition’ını unmount et ya da read-only olduğunu doğrula:

# Mevcut mount durumunu gör
mount | grep "/"

# Root'u remount read-only yap
mount -o remount,ro /

# Şimdi fsck çalıştır
fsck -y /dev/sda1

# Onarım sonrası remount read-write
mount -o remount,rw /

Live USB ile çalışıyorsan daha temiz bir ortamdır çünkü hedef disk hiç mount edilmemiştir:

# Live USB'den hangi diskler var?
lsblk
fdisk -l

# Hedef partition'ı kontrol et ve onar
sudo e2fsck -f -y /dev/sda1

Gerçek Dünya Senaryosu: Production Sunucusu Disk Hatası

Şöyle bir senaryo düşün. Sabah 6’da bir web sunucusundan alert geldi. Loglar yazılamıyor, uygulama hata veriyor. SSH ile bağlandında şunu gördün:

dmesg | tail -20

Çıktı şuna benzer bir şey gösterir:

[1234567.890] EXT4-fs error (device sdb1): ext4_find_entry:1455: inode #2: comm nginx: reading directory lblock 0
[1234568.012] EXT4-fs (sdb1): Remounting filesystem read-only

Disk read-only moda geçmiş. Bu durumda:

# Hangi servisler etkileniyor?
systemctl list-units --state=failed

# Log partition mı, data partition mı?
df -h
mount | grep sdb1

# Servisleri durdur
systemctl stop nginx
systemctl stop mysql  # eğer aynı diskteyse

# Unmount et
umount /dev/sdb1

# Eğer umount başarısız olursa (busy)
lsof /mnt/data | awk '{print $2}' | sort -u | xargs kill -9
umount /dev/sdb1

# Şimdi onar
e2fsck -f -y /dev/sdb1

# Sonucu kaydet
e2fsck -f -y /dev/sdb1 2>&1 | tee /tmp/fsck_report.txt

# Mount et ve servisleri başlat
mount /dev/sdb1 /mnt/data
systemctl start nginx

Kayıp Dosyalar ve lost+found Dizini

fsck onarım yaparken bazı dosyaları inode’larına göre kurtarır ama bu dosyaların hangi dizinde olduğunu bilemez. Bu dosyaları lost+found dizinine atar.

# lost+found içeriğini gör
ls -la /lost+found/

# Dosyaları incele
file /lost+found/*

# Metin dosyalarının içeriğine bak
for f in /lost+found/*; do
    echo "=== $f ==="
    head -5 "$f" 2>/dev/null
done

lost+found altındaki dosyalar genellikle inode numarasıyla isimlendirilir. İçeriklerine bakarak ne olduğunu anlayabilirsin. Önemli veriler burada olabilir; silmeden önce mutlaka incele.

# İnode numarasından orijinal dosya yolunu bulmaya çalış
# (eğer dosya sistemi çok bozuk değilse)
find / -inum 12345 2>/dev/null

Disk Sağlığını Önceden Kontrol Etmek

Fsck’ye gelmeden önce SMART verileriyle diskin sağlığını takip etmek çok daha akıllıca. Sorun olmadan önce uyarı alabilirsin.

# smartmontools kur
sudo apt install smartmontools   # Debian/Ubuntu
sudo dnf install smartmontools   # RHEL/Fedora

# Disk SMART durumu
sudo smartctl -a /dev/sda

# Kısa test (2 dakika)
sudo smartctl -t short /dev/sda

# Uzun test (saatler sürebilir)
sudo smartctl -t long /dev/sda

# Test sonucunu gör
sudo smartctl -l selftest /dev/sda

SMART çıktısında dikkat edilmesi gereken değerler:

Reallocated_Sector_Ct: 0’dan büyükse disk fiziksel hasarlı sektörleri taşıyor demek Current_Pending_Sector: Okunmayı bekleyen şüpheli sektörler var Offline_Uncorrectable: Düzeltilemez sektörler, ciddi uyarı Spin_Retry_Count: HDD için geçerli, motor sorunu işareti

Bu değerler yüksekse, fsck’den önce veriyi yedeklemeyi düşün. Disk ölmek üzere olabilir.

Bozuk Blokları Tespit Etme ve İşaretleme

badblocks aracı disk üzerindeki fiziksel bozuk blokları tespit eder. Bu bilgiyi e2fsck ile birlikte kullanabilirsin.

# Read-only bozuk blok taraması (yavaş ama güvenli)
sudo badblocks -v /dev/sdb1 > /tmp/bad_blocks.txt

# Sonuç dosyasını göster
cat /tmp/bad_blocks.txt

Eğer bozuk blok listesi doluysa, bu bloklara erişimi engellemek için e2fsck’ye verebilirsin:

sudo e2fsck -l /tmp/bad_blocks.txt /dev/sdb1

Bu sayede dosya sistemi gelecekte bu bloklara veri yazmaz.

Önemli uyarı: badblocks -w parametresi yazma testi yapar ve diskteki tüm veriyi siler. Sadece boş veya formatlanacak diskler için kullan.

Otomatik Fsck: Scheduled Check

Ext4 dosya sistemleri belirli mount sayısına veya süreye ulaşınca otomatik fsck çalıştırabilir. tune2fs ile bu ayarları görebilir ve değiştirebilirsin:

# Dosya sistemi bilgilerini göster
sudo tune2fs -l /dev/sdb1 | grep -E "Mount count|Maximum|Last checked|Check interval"

Çıktıda şunları görürsün:

Mount count:              47
Maximum mount count:      -1
Last checked:             Thu Jan  1 00:00:00 2024
Check interval:           0 (<none>)

Maximum mount count -1 ise otomatik kontrol devre dışı. Aktifleştirmek için:

# Her 30 mount'ta bir kontrol
sudo tune2fs -c 30 /dev/sdb1

# 6 ayda bir kontrol (saniye cinsinden değil, ay cinsinden)
sudo tune2fs -i 6m /dev/sdb1

# Her ikisini birden ayarla
sudo tune2fs -c 30 -i 6m /dev/sdb1

Modern sistemlerde systemd-fsck boot sırasında devreye girer. /etc/fstab dosyasındaki son sütun (pass numarası) fsck sırasını belirler:

cat /etc/fstab

# <device>     <mount>   <type>   <options>       <dump>  <pass>
/dev/sda1      /         ext4     defaults          1       1
/dev/sdb1      /data     ext4     defaults          0       2
/dev/sdc1      /backup   ext4     defaults          0       2

Pass 1: Root partition, en önce kontrol edilir Pass 2: Diğer partition’lar, root’tan sonra paralel kontrol edilebilir Pass 0: fsck bu partition’ı atlar (swap veya özel filesystem’lar için)

Fsck Çıktısını Anlama: Exit Code’lar

Script yazan bir sysadmin için fsck’nin döndürdüğü exit code’lar önemlidir:

0: Hata bulunamadı 1: Hatalar bulundu ve düzeltildi 2: Sistem reboot gerekiyor (kritik hatalar onarıldı) 4: Hatalar bulundu ama düzeltilemedi 8: Operasyonel hata (yanlış parametre gibi) 16: Kullanım hatası 32: Kontrol iptal edildi

Bunu bir script’e ekleyebilirsin:

#!/bin/bash

DEVICE="/dev/sdb1"
LOG="/var/log/fsck_$(date +%Y%m%d_%H%M%S).log"

echo "Fsck başlıyor: $DEVICE" | tee -a "$LOG"

# Unmount et
umount "$DEVICE" 2>&1 | tee -a "$LOG"

# Fsck çalıştır
e2fsck -f -y "$DEVICE" 2>&1 | tee -a "$LOG"
EXIT_CODE=$?

echo "Exit code: $EXIT_CODE" | tee -a "$LOG"

case $EXIT_CODE in
    0)
        echo "Dosya sistemi temiz, sorun yok." | tee -a "$LOG"
        ;;
    1)
        echo "Hatalar bulundu ve onarıldı, mount edilebilir." | tee -a "$LOG"
        ;;
    2)
        echo "UYARI: Kritik onarım yapıldı, reboot gerekli!" | tee -a "$LOG"
        ;;
    4)
        echo "HATA: Bazı hatalar düzeltilemedi, manuel müdahale gerekli!" | tee -a "$LOG"
        exit 1
        ;;
    *)
        echo "Beklenmeyen exit code: $EXIT_CODE" | tee -a "$LOG"
        exit 1
        ;;
esac

# Başarılıysa mount et
mount "$DEVICE" /mnt/data 2>&1 | tee -a "$LOG"
echo "İşlem tamamlandı." | tee -a "$LOG"

LVM ve RAID Ortamında Fsck

LVM üzerinde çalışıyorsan partition adları farklı görünür ama mantık aynıdır:

# LVM volume'leri listele
sudo lvdisplay
sudo lvs

# LVM üzerinde fsck
sudo umount /dev/mapper/ubuntu--vg-data
sudo e2fsck -f -y /dev/mapper/ubuntu--vg-data
sudo mount /dev/mapper/ubuntu--vg-data /data

Software RAID (mdadm) kullanıyorsan önce RAID durumunu kontrol et:

# RAID durumunu gör
cat /proc/mdstat
sudo mdadm --detail /dev/md0

# RAID sağlıklıysa üzerindeki fs'i kontrol et
sudo umount /dev/md0
sudo e2fsck -f -y /dev/md0

Eğer RAID degraded durumdaysa (bir disk çalışmıyor), önce RAID’i düzeltmek gerekir, yoksa fsck her geçişte tutarsızlıkla karşılaşabilir.

Fsck Sonrası: Veri Doğrulama

Onarım bitti, disk mount edildi. Ama her şey yolunda mı? Birkaç kontrol daha:

# Dosya sistemi istatistikleri
df -h /mnt/data
sudo dumpe2fs -h /dev/sdb1 | grep -E "Filesystem state|Errors behavior"

# Bir süre sonra dmesg'de yeni hata var mı?
dmesg -T | grep -E "EXT4|I/O error" | tail -20

# Disk read/write testi (dikkatli kullan, hafif yük oluşturur)
sudo dd if=/dev/sdb1 of=/dev/null bs=1M count=1000 status=progress

# Dosya bütünlüğü için basit bir kontrol
find /mnt/data -type f -readable -exec md5sum {} ; > /tmp/checksums_after.txt
# Önceden bir checksum dosyan varsa karşılaştır

Önleyici Tedbirler: Kapanış

Gerçek sysadmin bilgeliği şuradan gelir: En iyi fsck operasyonu, hiç yapılmayan operasyondur.

Pratik öneriler:

UPS kullan: Güç kesintisi ext4 için en büyük tehditlerden biri, journal kurtarsada donanım seviyesinde kayıp olabilir
SMART monitoring kur: smartd servisi disk sorunlarını erkenden haber verir, /etc/smartd.conf ile mail alert kurulabilir
Düzenli snapshot al: LVM veya ZFS snapshot’ları fsck yapmadan önce geri dönüş noktası sağlar
Mount option’larına dikkat et: errors=remount-ro varsayılan ayar, hata durumunda read-only moda geçer, bu aslında iyi bir davranış
Kritik diskleri izle: iostat, iotop, sar ile I/O anomalilerini yakala

Sonuç

Fsck, Linux sysadmin’in en temel araçlarından biri. Doğru kullanıldığında ciddi veri kayıplarının önüne geçer. Yanlış kullanıldığında, özellikle mount edilmiş bir diskte çalıştırıldığında, var olan sorunu katlamalı hale getirir.

Kritik noktalara bir daha bakalım: Hiçbir zaman mount edilmiş bir dosya sisteminde fsck çalıştırma. Onarım öncesi mümkünse yedek al ya da en azından SMART durumunu kontrol et. Çıktıyı bir log dosyasına yaz, gelecekteki sorun analizinde işe yarar. Exit code’ları anla ve script’lerinde kullan. Süperblok yedeklerini bilmek, gece 2’deki paniği saate, hatta dakikaya indirir.

Disk sorunları kaçınılmazdır. Ama hazırlıklı olmak, onları felaketten rutin bir operasyona dönüştürür. Bu araçları test ortamında dene, komutları ezberle ve bir dahaki production krizi geldiğinde hazır ol.

ext4 Dosya Sisteminde fsck ile Hata Onarımı