TEKNİK YAZI / Backend Sistemleri

fsck ile Linux Dosya Sistemi Denetimi ve Onarımı

fsck ile Linux dosya sistemini güvenle denetleme ve onarma: salt okunur denetim, ext4, XFS ve Btrfs için doğru araç, kök dosya sistemi ve çıkış kodları.

Yayınlandı: Güncellendi:

fsck, Linux’ta dosya sistemi tutarlılığını denetleyen ve desteklenen durumlarda onaran araçların ortak ön yüzüdür. Yanlış aygıtta ya da bağlı bir dosya sisteminde onarım çalıştırmak veri kaybını büyütebileceği için komuttan önce dosya sistemi türünü, aygıt yolunu ve yedek durumunu doğrulamak gerekir. Yazı, fsck’nin ne zaman çalıştığını, salt okunur denetimi, ext4, XFS ve Btrfs için doğru aracı, kök dosya sisteminin nasıl denetleneceğini ve çıkış kodlarını ele alır.

fsck nedir?

fsck, “file system consistency check” (dosya sistemi tutarlılık denetimi) ifadesinin kısaltmasıdır ve Windows’taki chkdsk komutunun Linux’taki karşılığı olarak düşünülebilir. Elektrik kesintisi, sistem çökmesi, donanım arızası veya bozuk sektörler dosya sistemi meta verisinde tutarsızlık oluşturabilir. fsck bu yapıları dosya sistemine özgü bir denetleyiciyle inceler; onarım kapasitesi ve güvenli çalışma koşulları dosya sistemine göre değişir.

fsck ne zaman çalışır?

Açılışta, otomatik olarak: /etc/fstab içindeki altıncı alan (passno) 0’dan büyük olan dosya sistemleri açılışta denetlenir. systemd kullanan sistemlerde bu işi systemd-fsck servisleri yapar; denetimin gerçekten yapılıp yapılmayacağına ise dosya sistemine özgü denetleyici karar verir. ext ailesinde e2fsck tam denetimi şu durumlarda yapar:

Journal’lı ext3 ve ext4’te yalnız anormal bir kapanma yaşandıysa e2fsck genellikle journal’ı oynatıp çıkar. Periyodik denetim sayaçları e2fsprogs 1.42 (2011) ve sonrasında yeni oluşturulan dosya sistemlerinde varsayılan olarak kapalıdır; sudo tune2fs -l /dev/sdaX çıktısında Maximum mount count değeri -1 ise bağlama sayısına bakılmaz.

Elle çalıştırmanız gereken durumlar:

G/Ç beklerken takılan süreçler ps çıktısında D durumunda görünür ve SIGKILL ile de sonlanmaz; bu belirtinin anlamı Linux kill ve PID yazısında anlatılıyor. Böyle bir tabloda dosya sisteminden önce diskin kendisini şüpheli saymak gerekir.

fsck neyi denetler?

ext ailesinde e2fsck denetimi beş geçişte (pass) yapar ve çıktısında her geçişi ayrı satırda gösterir:

  1. Inode’lar, bloklar ve boyutlar: Her inode’un geçerliliği ve kullandığı bloklar denetlenir. Aynı blok birden fazla dosya tarafından sahiplenilmişse 1B, 1C ve 1D alt geçişleri bu çakışmayı çözer.
  2. Dizin yapısı: Dizin girdilerinin geçerli inode’ları gösterip göstermediği denetlenir.
  3. Dizin bağlantısı: Her dizinin kökten erişilebilir olduğu doğrulanır; bağlantısı kopmuş dizinler lost+found altına bağlanır.
  4. Referans sayıları: Her inode’un bağlantı sayısı (link count) gerçek referanslarla karşılaştırılır; hiçbir dizinden gösterilmeyen sahipsiz inode’lar lost+found altına bağlanır.
  5. Grup özetleri: Blok ve inode bit eşlemleri ile boş alan sayaçları gerçek kullanımla karşılaştırılır.

Birincil superblock okunamıyorsa e2fsck’ye -b seçeneğiyle yedek superblock’lardan biri verilebilir.

Temel kural: onarım bağlı dosya sisteminde yapılmaz

e2fsck kılavuzu kuralı açıkça koyar: bağlı (mounted) bir dosya sisteminde e2fsck çalıştırmak genel olarak güvenli değildir. Tek istisna -n seçeneğidir; kılavuz bu durumda bile, dosya sistemi bağlı olduğu için yazdırılan sonuçların geçerli olmadığını belirtir. Bağlı bir dosya sisteminde onarım, çekirdeğin önbelleğindeki durum ile aracın diskte gördüğü durumu ayrıştırır ve bozulmayı büyütebilir. Pratik kural şudur:

Temel kullanım

İlk adım her zaman aygıtı ve dosya sistemi türünü doğrulamaktır. Yanlış aygıt seçmek bu araçla yapılabilecek en pahalı hatadır:

lsblk -f
sudo blkid /dev/sda1

Salt okunur denetim:

# Hiçbir değişiklik yazmaz, tüm sorulara "hayır" yanıtı verir
sudo fsck -n /dev/sda1

# Aynı denetim, ayrıntılı çıktıyla (-v, e2fsck'ye aktarılır)
sudo fsck -n -v /dev/sda1

-v tek başına salt okunur bir kip değildir. -n, -p veya -y verilmezse e2fsck etkileşimli kipte çalışır ve bulduğu her sorun için onarım onayı ister. fsck’nin tanımadığı seçenekler dosya sistemine özgü denetleyiciye aktarılır; fsck’nin kendi ayrıntı seçeneği büyük harfli -V’dir ve çalıştırılan denetleyici komutunu gösterir.

Onarım seçenekleri:

# Açılışta kullanılan kip: yalnız güvenle düzeltilebilen sorunları onarır
sudo fsck -p /dev/sda1

# Tüm sorulara "evet": etkisini bildiğinizde kullanın
sudo fsck -y /dev/sda1

# Temiz işaretli olsa bile denetlemeye zorla
sudo fsck -f /dev/sda1

-p (preen) ile -y arasındaki fark önemlidir. -p yalnız insan müdahalesi gerektirmeden güvenle düzeltilebilen sorunları onarır; karar gerektiren bir sorunla karşılaşırsa açıklamasını yazar ve çıkış koduna 4 ekleyerek durur. -y ise her soruya evet yanıtı vererek devam eder. -f tek başına tehlikeli değildir: temiz görünen bir dosya sistemini de baştan sona taradığı için yalnız süreyi uzatır.

-c seçeneğinin adı yanıltıcıdır. Bozuk sektörleri onarmaz; badblocks ile salt okunur bir tarama yapar ve bulduğu blokları dosya sisteminin bir daha kullanmayacağı biçimde işaretler. İşlem saatler sürebilir ve sektörleri kendi içinde yeniden eşleyen güncel disklerde yararı sınırlıdır. Fiziksel disk arızası şüphesinde doğru adım, smartctl ile diskin SMART (S.M.A.R.T.) verisini okumaktır.

-A seçeneği /etc/fstab içindeki tüm dosya sistemlerini denetler ve açılış betikleri için tasarlanmıştır. Çalışan bir sistemde elle çağrıldığında bağlı dosya sistemlerini, kök dosya sistemi dâhil, hedef alır; bu yüzden günlük kullanımda önerilmez.

Dosya sistemine göre doğru araç

fsck tek başına bir denetleyici değil, bir ön yüzdür: aygıtın dosya sistemi türünü belirler ve işi fsck.<tür> adlı programa devreder. Bu devretme her dosya sisteminde gerçek bir denetim anlamına gelmez.

Bu ayrımın pratik sonucu: XFS veya Btrfs bir aygıtta fsck çalıştırmak temiz bir çıktı ve sıfır çıkış kodu üretir, fakat hiçbir denetim yapılmamıştır. Çıktının temiz görünmesi, dosya sisteminin denetlendiği anlamına gelmez.

XFS için sıra şöyledir:

# Türü ve aygıtı doğrula
lsblk -f

# Dosya sistemini ayır
sudo umount /dev/sda1

# Önce salt okunur denetim
sudo xfs_repair -n /dev/sda1

# Gerekliyse onarım
sudo xfs_repair /dev/sda1

xfs_repair, journal’ın oynatılmış olmasını bekler. Kirli bir journal ile karşılaşırsa dosya sistemini bir kez bağlayıp yeniden ayırmak gerekir. -L seçeneği journal’ı sıfırlar; veri kaybına yol açabileceği için yalnız başka yol kalmadığında kullanılır.

Btrfs için karşılığı sudo btrfs check /dev/sda1 komutudur; --repair eklenmeden önce yedek alınmalıdır.

Kök dosya sistemini denetlemek

Kök dosya sistemi çalışan sistemde ayrılamaz. Onu denetlemenin iki güvenli yolu vardır.

Açılışta denetim: fsck.mode ve fsck.repair

systemd kullanan sistemlerde systemd-fsck, çekirdek komut satırındaki iki parametreyi tanır:

Bu parametreler yalnız /etc/fstab içinde passno değeri 0’dan büyük olan ve açılışta bağlanan dosya sistemlerine uygulanır. initrd kullanan sistemlerde kök dosya sistemi initrd aşamasında denetlenir. Denetim initrd’de yapılmadıysa işi systemd-fsck-root üstlenir: kök dosya sistemini denetleyen fsck “sistem yeniden başlatılmalı” (2) sonucunu döndürürse sistemi yeniden başlatır. Böylece çekirdek, onarım sırasında diskte değişen yapının eski bir görüntüsüyle çalışmaya devam etmez; bağlı dosya sisteminde onarımın asıl riski bu yeniden başlatmayla sınırlanır. Tek seferlik kullanım için GRUB menüsünde ilgili girdinin üzerindeyken e tuşuna basın, linux ile başlayan satırın sonuna fsck.mode=force ekleyin ve Ctrl+X ile başlatın; değişiklik kalıcı olmaz. systemd birimlerinin genel yapısı systemd servis yazısında anlatılıyor.

Live USB

Ayrıntılı inceleme veya xfs_repair -L gibi riskli bir onarım gerekiyorsa en güvenli yol, sistemi harici bir ortamdan başlatıp hedef dosya sistemini hiç bağlamadan denetlemektir:

lsblk -f                     # aygıtı ve türü belirle
sudo fsck -n /dev/sda2       # önce salt okunur
sudo fsck /dev/sda2          # gerekliyse onar

Kurtarma kipi hakkında

GRUB’daki kurtarma kipi (recovery mode) ve tek kullanıcı kipi (single user mode) kök dosya sistemini bağlı hâlde bırakır; dosya sisteminin salt okunur bağlı olması onarım için yeterli değildir. Açılıştaki denetimin aksine bu kiplerde onarımdan sonra sistemi hemen yeniden başlatan bir mekanizma da yoktur. Bu kiplerde kök dosya sistemi için yalnız durum tespiti yapın, onarımı açılış parametresine veya live USB’ye bırakın:

sudo mount -o remount,ro /
sudo fsck -n /dev/sda2

Çıkış kodları

fsck(8) kılavuzuna göre çıkış kodu aşağıdaki durumların toplamıdır:

Örneğin 5 (4 + 1), bazı hataların düzeltildiğini fakat bazılarının kaldığını gösterir. Birden fazla dosya sistemi denetlendiğinde döndürülen kod, her birinin çıkış kodunun bit düzeyinde VEYA (bitwise OR) işlemiyle birleştirilmesidir. Bu yüzden betiklerde sonucu eşitlikle değil, rc & 4 gibi bit maskesiyle sınamak gerekir.

lost+found dizini

e2fsck, bağlantısı kopmuş dosya ve dizinleri kökteki lost+found dizinine, adları inode numarasından türetilen girdiler olarak bağlar. Bu dizin ext ailesine özgüdür: mke2fs onu dosya sistemi oluşturulurken kökte hazırlar ve kurtarma sırasında e2fsck’nin yeni blok ayırması gerekmesin diye ona önceden yer ayırır; silinmişse mklost+found ile yeniden oluşturulabilir. XFS’te bu dizin önceden bulunmaz; xfs_repair sahipsiz dosyaları bağlaması gerektiğinde onu oluşturur. Btrfs’te de önceden oluşturulmuş böyle bir dizin yoktur.

lost+found içinde inode numarasıyla adlandırılmış dosyalar bulursanız, bunlar denetleyicinin kurtardığı fakat özgün adını ve konumunu belirleyemediği dosyalardır. İçeriklerini file komutuyla inceleyip gerekli olanları yerine taşıyabilirsiniz.

Önlemler

Dikkat edilecek durumlar

Sonuç

fsck rutin bir bakım aracı değil, dosya sistemi tutarlılığı için kontrollü bir kurtarma aracıdır. Önce yedek ve aygıt envanteri alın, dosya sistemini ayırın, türüne uygun aracı seçin ve otomatik onarım seçeneklerini etkisini anladıktan sonra kullanın. Fiziksel disk arızası şüphesinde onarımdan önce disk sağlığını değerlendirmek ve verinin kopyasını almak daha güvenlidir.

Birincil kaynaklar