Ubuntu’da Dosya Sistemi Kontrol ve Onarımı: fsck Kullanım Kılavuzu

yazar

Bir gün sunucuna bağlandığında terminalde seni bekleyen o korkunç mesajı muhtemelen en az bir kez görmüşsündür: “Input/output error” ya da daha da kötüsü, sistem açılışta fsck ekranında takılı kalmış. İşte tam bu noktada dosya sistemi sağlığı konusunda ne kadar bilgili olduğun kritik hale geliyor. fsck (File System Consistency Check) aracı, Linux dünyasında disk ve dosya sistemi sorunlarını tespit edip onarmak için kullanılan temel araçlardan biridir. Yanlış kullanıldığında veri kaybına yol açabilir, doğru kullanıldığında ise seni ciddi bir felaketten kurtarabilir.

fsck Nedir ve Ne Zaman Kullanılır?

fsck, dosya sisteminin tutarlılığını kontrol eden ve bulduğu hataları onaran bir komut satırı aracıdır. Aslında fsck tek bir program değil, her dosya sistemi türü için ayrı bir arka uç programı çağıran bir ön yüzdür. fsck.ext4, fsck.xfs, fsck.vfat gibi araçları arka planda çalıştırır.

Ne zaman fsck çalıştırmalısın?

  • Sistem ani kapanma veya elektrik kesintisi sonrası beklenmedik davranışlar gösteriyorsa
  • “Structure needs cleaning” veya “Input/output error” hataları alıyorsan
  • Diskten okuma/yazma yapılamıyorsa
  • Sistem açılışta otomatik olarak fsck ekranına düşüyorsa
  • Periyodik bakım planı kapsamında (sistemi düzenli kontrol etmek istiyorsan)
  • SMART testleri disk sektör hatalarını raporluyorsa

Şunu baştan netleştirmek gerekiyor: fsck, bağlı (mount edilmiş) bir dosya sistemi üzerinde çalıştırılmamalıdır. Bu kuralı çiğnersen veri bozulması kaçınılmazdır. Tek istisna, bazı modern dosya sistemlerinin (XFS gibi) çevrimiçi kontrole sınırlı destek vermesidir, ama bu konuya sonra geleceğiz.

Temel Söz Dizimi ve Parametreler

fsck komutunun temel kullanımı şu şekildedir:

fsck [seçenekler] <aygıt>

Sık kullanılan parametreler:

  • -a: Tüm hataları otomatik olarak onarmaya çalışır (etkileşimsiz mod, dikkatli kullan)
  • -r: Her hata için sormak istediği zaman kullanıcıya sorar (etkileşimli mod)
  • -n: Salt okunur mod, hiçbir değişiklik yapmadan sadece hataları listeler
  • -y: Tüm sorulara otomatik olarak “yes” yanıtı verir
  • -f: Dosya sistemi temiz görünse bile zorla kontrol eder
  • -v: Ayrıntılı çıktı (verbose)
  • -C: İlerleme çubuğu gösterir (ext2/ext3/ext4 için)
  • -t: Dosya sistemi türünü belirtir
  • -A: /etc/fstab dosyasındaki tüm dosya sistemlerini kontrol eder
  • -M: Bağlı dosya sistemlerini atlayarak güvenli çalışır
  • -p: Kullanıcı onayı istemeden güvenli onarımları otomatik yapar

Hangi Disk Nereden Bakılır?

Önce sisteminizde hangi disklerin ve bölümlerin olduğunu görmeniz gerekiyor:

lsblk -f

Bu komut, disk bölümlerini ve üzerlerindeki dosya sistemi türlerini, UUID’leri ve mount noktalarını bir ağaç yapısında gösterir. Daha detaylı bilgi için:

df -hT

Belirli bir diskin durumunu kontrol etmek için:

sudo fdisk -l /dev/sda

Şimdi gerçek dünyadan bir örnek verelim. Diyelim ki /dev/sdb1 bölümünde sorun şüpheleniyorsun. Bu bölümün bağlı olup olmadığını kontrol et:

mount | grep sdb1

Eğer bağlıysa, önce ayır:

sudo umount /dev/sdb1

Umount başarısız olursa ve bölüm meşgulse, hangi işlemler kullandığını görmek için:

sudo lsof /dev/sdb1
# veya
sudo fuser -m /dev/sdb1

İlk Kontrol: Salt Okunur Modda Çalıştırmak

Herhangi bir değişiklik yapmadan önce sorunların boyutunu anlamak için -n parametresiyle çalıştır:

sudo fsck -n /dev/sdb1

Bu komut dosya sistemini kontrol eder ama hiçbir şeyi değiştirmez. Çıktıya bakarak durumu değerlendirirsin. Temiz bir sistemde şuna benzer bir çıktı görürsün:

fsck from util-linux 2.37.2
e2fsck 1.46.5 (30-Dec-2021)
/dev/sdb1: clean, 128456/3276800 files, 1893421/13107200 blocks

Eğer hatalar varsa çıktı çok daha uzun ve ayrıntılı olacak. Bu aşamada paniklemeden not al, çünkü onarım adımında neyle uğraştığını bilmen önemli.

ext4 Dosya Sistemi Onarımı

Ubuntu’da en yaygın karşılaştığın dosya sistemi ext4 olacak. Rootfs dışındaki bir bölümü onarmak için:

sudo fsck.ext4 -f -y /dev/sdb1

Burada -f ile temiz görünse bile zorla kontrol ettiriyorsun, -y ile de tüm onarım sorularına otomatik “evet” diyorsun. Eğer ne onayladığını görmek istiyorsan -y yerine -r kullan ve her soruyu elle yanıtla.

Verbose modda daha fazla bilgi almak için:

sudo fsck.ext4 -f -v /dev/sdb1

Onarım bittikten sonra her zaman ikinci bir kontrol yapmayı alışkanlık edin:

sudo fsck.ext4 -n /dev/sdb1

Bu sefer “clean” çıktısı görmelisin.

Root Dosya Sistemi: İşin En Kritik Kısmı

Root bölümünü (/) onarmak istediğinde işler karmaşıklaşıyor çünkü sistem çalışırken bu bölüme dokunman mümkün değil. Birkaç yolun var:

Yöntem 1: Açılışta fsck Zorlamak

Bir sonraki açılışta fsck’in çalışmasını zorlamak için boş bir dosya oluştur:

sudo touch /forcefsck

Ya da tune2fs ile:

sudo tune2fs -C 1 /dev/sda1

Sistemi yeniden başlat, açılış sürecinde fsck otomatik devreye girecek.

Yöntem 2: Recovery Mode Kullanmak

Ubuntu’yu yeniden başlat ve GRUB menüsünde “Advanced options for Ubuntu” seçeneğine gir. Oradan “recovery mode” seçeneğini seç. Recovery menüsünde “fsck” seçeneğini kullanarak root dosya sistemini kontrol edebilirsin.

Yöntem 3: Live USB ile Çalışmak

Üretim sunucularında en güvenli yöntem bu. Ubuntu Live USB ya da herhangi bir Linux Live medyasıyla sistemi başlat, sunucunun diskleri bağlanmamış halde olacak, rahatça fsck çalıştırabilirsin:

# Live sistemde hangi bölümlerin olduğunu gör
lsblk -f

# Root bölümünü kontrol et (bağlamadan)
sudo fsck.ext4 -f /dev/sda1

Gerçek Dünya Senaryosu: Açılmayan Sunucu

Geçen yıl bir müşterinin sunucusu elektrik kesintisi sonrası açılmıyordu. Sunucu GRUB’da takılı kalıyordu. Ubuntu Live USB ile sistemi başlatıp şu adımları izledim:

# Diskleri listele
lsblk -f

# Root bölümünü kontrol et
sudo fsck.ext4 -f -y /dev/sda2

# Swap bölümünü de kontrol et
sudo fsck -f /dev/sda3

# Boot bölümünü kontrol et
sudo fsck.vfat /dev/sda1

ext4 kontrolü yüzlerce orphaned inode ve bir grup descriptor hatası buldu. -y parametresi sayesinde hepsini otomatik onardı. Sunucu normal şekilde açıldı. Ama şunu vurgulamak istiyorum: bu senaryoda önce yedek almak şart. Eğer yedek almadan müdahale edersek ve onarım işe yaramazsa, durumu daha da kötüleştirebiliriz.

e2fsck ile Gelişmiş ext4 Analizi

e2fsck, ext2/ext3/ext4 dosya sistemleri için özelleşmiş bir araçtır ve fsck.ext4 komutunun aslında çağırdığı programdır. Daha ayrıntılı kontrol seçenekleri sunar:

# Süper blok bozulmuşsa yedek süper blokla dene
sudo e2fsck -b 32768 /dev/sdb1

# Yedek süper bloğun nerede olduğunu öğrenmek için
sudo mke2fs -n /dev/sdb1

Süper blok bozulması ciddi bir durumdur. ext4, bu duruma karşı birden fazla yedek süper blok saklar. mke2fs -n komutu diski formatlamamaz, sadece süper blokların nerede olacağını hesaplayarak listeler.

Bir diğer yararlı araç dumpe2fs; dosya sistemi hakkında detaylı bilgi verir:

sudo dumpe2fs /dev/sdb1 | grep -i "check|mount|error"

Bu çıktıda son kontrol zamanını, mount sayısını ve hata durumunu görebilirsin.

tune2fs ile Periyodik Kontrol Ayarları

Ubuntu, ext4 dosya sistemlerini belirli aralıklarla otomatik kontrol eder. Bu davranışı tune2fs ile yönetebilirsin:

# Mevcut ayarları göster
sudo tune2fs -l /dev/sda1 | grep -i "mount|check|interval"

# Her 30 mount'ta bir kontrol yap (0 = devre dışı)
sudo tune2fs -c 30 /dev/sda1

# 6 ayda bir kontrol yap (saniye cinsinden)
sudo tune2fs -i 6m /dev/sda1

# Otomatik kontrolü tamamen kapat (üretim sunucuları için bazen tercih edilir)
sudo tune2fs -c 0 -i 0 /dev/sda1

Üretim sunucularında otomatik açılış kontrolünü kapatıp, planlı bakım penceresinde manuel fsck yapmayı tercih eden sysadminler var. Bu yaklaşım, sunucunun beklenmedik bir anda uzun fsck sürecine girmesini önler.

XFS ve Diğer Dosya Sistemleri

Ubuntu 20.04 ve sonrasında bazı yapılandırmalarda XFS de karşına çıkabilir. XFS için xfs_repair kullanılır:

# XFS dosya sistemini kontrol et
sudo xfs_repair -n /dev/sdb1

# Onar
sudo xfs_repair /dev/sdb1

XFS’in bir özelliği, bağlı durumdayken log temizleme desteğidir ama genel onarım için yine de unmount gerekmektedir. Eğer XFS log’ları bozulmuşsa:

sudo xfs_repair -L /dev/sdb1

Dikkat: -L seçeneği log’u temizler ve bu veri kaybına yol açabilir. Başka seçenek kalmadığında başvurulacak son çaredir.

btrfs kullananlar için:

sudo btrfs check /dev/sdb1
# Onarım için (son derece dikkatli kullan)
sudo btrfs check --repair /dev/sdb1

FAT32 veya vfat bölümleri (USB diskler, EFI bölümleri) için:

sudo fsck.vfat -a /dev/sdc1

Disk SMART Durumu ile fsck’i Birlikte Değerlendirmek

fsck dosya sistemi katmanında çalışır, donanım katmanında değil. Eğer diskin fiziksel olarak bozuluyorsa, fsck onarımları kalıcı olmayacaktır. Bu yüzden her cidli disk sorununda önce SMART durumunu kontrol et:

# smartmontools yüklü değilse
sudo apt install smartmontools

# Hızlı SMART testi
sudo smartctl -H /dev/sda

# Detaylı rapor
sudo smartctl -a /dev/sda

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

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

SMART raporu “FAILED” diyorsa veya çok sayıda “Reallocated Sector Count” ya da “Pending Sector Count” gösteriyorsa, disk fiziksel olarak bozuluyor demektir. Bu durumda yapılacak tek doğru şey acil yedek almak ve diski değiştirmek. fsck ile vakit kaybetme.

fsck Çıktısı Nasıl Yorumlanır?

fsck işlemi tamamlandığında bir çıkış kodu döner:

  • 0: Hata yok, dosya sistemi temiz
  • 1: Hatalar bulundu ve düzeltildi
  • 2: Sistem yeniden başlatılmalı (ciddi düzeltmeler yapıldı)
  • 4: Düzeltilemeyen hatalar bulundu
  • 8: Operasyonel hata (yanlış parametre vs.)
  • 16: Kullanım hatası veya söz dizimi hatası
  • 32: Kullanıcı tarafından iptal edildi
  • 128: Paylaşımlı kütüphane hatası

Bu çıkış kodlarını script’lerde kullanabilirsin:

#!/bin/bash
sudo fsck -n /dev/sdb1
EXIT_CODE=$?

if [ $EXIT_CODE -eq 0 ]; then
    echo "Dosya sistemi temiz."
elif [ $EXIT_CODE -eq 1 ]; then
    echo "Hatalar bulundu ve düzeltildi."
elif [ $EXIT_CODE -ge 4 ]; then
    echo "KRİTİK: Düzeltilemeyen hatalar! Acil müdahale gerekli."
    # Buraya bildirim gönderme kodu eklenebilir
fi

systemd-fsck ve Açılış Süreci

Modern Ubuntu sistemlerde açılış sırasındaki fsck işlemi systemd-fsck servisi tarafından yönetilir. Bu servisin davranışını /etc/systemd/system.conf dosyasında ve kernel parametreleriyle kontrol edebilirsin.

Açılışta fsck günlüklerini görmek için:

sudo journalctl -u [email protected]
# veya tüm fsck logları için
sudo journalctl -k | grep -i fsck

Bir sonraki açılışta tüm dosya sistemlerini kontrol ettirmek istiyorsan:

sudo systemctl enable [email protected]

Kernel parametresiyle de kontrol edebilirsin. GRUB ayarlarında fsck.mode=force eklemek tüm dosya sistemlerini zorla kontrol ettirir.

Önleyici Bakım ve İzleme

Sorun çıkmadan önce almak istediğin bazı önlemler:

# Düzenli SMART izleme için smartd servisini etkinleştir
sudo systemctl enable smartd
sudo systemctl start smartd

# /etc/smartd.conf içinde disk izleme kuralı ekle
# Her gün kontrol et, problem varsa mail gönder
echo "/dev/sda -a -d auto -s S/../.././02 -m [email protected]" | sudo tee -a /etc/smartd.conf

# Dosya sistemi hata istatistiklerini periyodik gözden geçir
sudo tune2fs -l /dev/sda1 | grep -i "filesystem state|error behavior|mount count"

Ayrıca dmesg çıktısını düzenli takip et:

sudo dmesg | grep -iE "error|fail|corrupt|bad sector|i/o error"

Bu komutun çıktısını bir cron job ile günlük mail olarak kendinize gönderebilirsiniz. Küçük sinyalleri erken yakalamak, büyük felaketleri önler.

Önemli Uyarılar ve Sık Yapılan Hatalar

Bağlı dosya sistemine fsck çalıştırmak: En tehlikeli hata bu. Sistem çalışırken / veya başka bağlı bir bölüme fsck uygularsan, veri bozulması garanti.

Yedek almadan onarıma girişmek: fsck bazen hatalı gördüğü yapıları siler. “lost+found” dizinine atılan dosyalar kurtarılabilir olsa da veri kaybı riski her zaman vardır. Kritik sistemlerde önce disk imajı al:

sudo dd if=/dev/sdb of=/backup/sdb_image.img bs=4M status=progress

-y parametresini körü körüne kullanmak: Otomatik “yes” modu hızlıdır ama ne onayladığını görmezsin. Test veya kritik olmayan sistemlerde uygun olsa da üretimde etkileşimli modu tercih et.

XFS’te fsck.ext4 çalıştırmaya çalışmak: Her dosya sistemi kendi aracını gerektirir. Yanlış araç kullanmak ciddi hasara yol açar. Her zaman önce lsblk -f ile dosya sistemi türünü doğrula.

Sonuç

fsck, sysadmin’in en değerli araçlarından biridir, ama dikkat ve bilgi gerektiren bir araç. Temel kuralları hatırlamak gerekirse: çalıştırmadan önce unmount et, kritik sistemlerde önce yedek al, dosya sistemi türüne uygun aracı kullan ve SMART verisiyle birlikte değerlendir.

Disk sorunlarının çoğu erken tespit edildiğinde kolayca çözülebilir. Bunu sağlamak için periyodik izleme, dmesg takibi ve planlı bakım pencerelerinde düzenli fsck kontrolü alışkanlık haline getirilmeli. Reaktif değil proaktif olmak, bir sunucu yöneticisinin en büyük silahıdır.

Bir dahaki sefere terminalde o korkunç I/O hata mesajını gördüğünde paniklemek yerine, adım adım ilerle: diski tanı, SMART’ı kontrol et, unmount et, fsck çalıştır ve sonuçları değerlendir. Çoğu zaman durum göründüğü kadar kötü değildir.

Yorum yapın