strace ile Debugging Ne Zaman Yeterli Değildir? Sınırlar, Riskler ve Gözlemcinin Laneti

Bir önceki yazımızda strace ile Linux’ta Görünmeyeni Görmek konusunu derinlemesine inceledik. Artık elinizde bir “X-Ray cihazı” var ve kendinizi sistemin hakimi gibi hissediyorsunuz. Herhangi bir hata aldığınızda refleks olarak parmaklarınız strace -p <PID> komutuna gidiyor.

Bu harika bir his. Ancak çok tehlikeli bir yanılgı. Bazen o “X-Ray cihazı”, hastayı iyileştirmek yerine öldürebilir. Bazen de cihaz çalışır ama ekranda hiçbir şey göremezsiniz; hasta ise can çekişmeye devam eder.

Bu yazıda, strace fanatikliğinin bittiği ve gerçek Sistem Mühendisliğinin başladığı gri alana gireceğiz. Production ortamında bir sistemi nasıl yanlışlıkla çökertebileceğinizi, “Gözlemci Etkisi”ni (Observer Effect) ve strace‘in neden bazen size yalan söylediğini konuşacağız.

📌 Bu Yazıda Ne Öğreneceksin?

Bu yazının sonunda:

• “Gözlemci Etkisi” (Observer Effect) yüzünden production ortamındaki bir sistemi nasıl yanlışlıkla göçertebileceğinizi anlayacaksınız
• ptrace mekanizmasının kaputun altında nasıl çalıştığını ve her syscall’ın faturasını göreceksiniz
• “strace çalışıyor ama ekran boş” dediğiniz anlarda, sorunun vDSO, mmap veya Asenkron I/O kaynaklı olup olmadığını ayırt edebileceksiniz
• Donmuş bir süreçte (Deadlock) strace işe yaramadığında, pstack veya gdb ile nasıl röntgen çekeceğinizi öğreneceksiniz
• Hangi durumda strace, hangi durumda perf veya eBPF kullanmanız gerektiğine dair net bir karar matrisine sahip olacaksınız

Kısacası; strace’in “Her derde deva” olmadığını, bazen ilacın kendisinin zehir olabileceğini öğreneceksiniz.

☠️ 1. Gözlemcinin Laneti: Production’da strace Kullanmak

Kuantum fiziğinde Heisenberg Belirsizlik İlkesine benzer bir durum, sistem izlemede de geçerlidir: Bir sistemi gözlemlemek, o sistemin davranışını değiştirir.

⚙️ Kaputun Altı: ptrace Mekanizması

strace, Linux çekirdeğinin sunduğu ptrace(2) (Process Trace) sistem çağrısını kullanır. Bu mekanizma, bir programın (tracer) başka bir programı (tracee) durdurmasını ve hafızasını okumasını sağlar.

🧠 Teknik Detay: ptrace (Process Trace)

ptrace, Linux’un “hata ayıklama” (debugging) omurgasıdır. Bir sürecin, başka bir sürecin hafızasına (RAM) ve kayıtçılarına (Register) erişmesini sağlar.

• Yetki: Sadece dosya sahibi veya ROOT kullanıcısı yapabilir.
• Risk: ptrace ile bağlandığınız süreç, siz işinizi bitirene kadar durur (SIGSTOP).

Ancak bu işlem “bedava” değildir. Arka planda şu adımlar gerçekleşir:

1. Entry Trap (Giriş Yakalaması): İzlenen program bir syscall (örn: read) çağırdığında, çekirdek (Kernel) normal akışı keser ve CPU’yu durdurur. Buna teknik dilde “Trap” (Tuzak/Yakalama) denir. “Dur bakalım, kimlik kontrolü!” anıdır.
2. Context Switch #1 (App -> Tracer): Kernel, kontrolü dümendeki strace sürecine geçirir.

🧠 Teknik Detay: Context Switch (Bağlam Değiştirme)

İşlemcinin (CPU), o an çalıştığı programı bırakıp başka bir programa geçmesidir.

• Maliyet: İşlemci önce elindeki işi (Register’lar, Hafıza Haritası) kaydetmeli, sonra yeni işin bilgilerini yüklemelidir.
• Analoji: Bir yazarın roman yazarken aniden durup, vergi beyannamesi doldurmaya başlaması ve sonra tekrar romana dönmesidir. Bu “odak değişimi” zihinsel enerji (CPU Cycle) harcar.
  1. Inspection (Veri Okuma): strace uyanır ve durdurulan programın Register‘larını (işlemcinin o anlık not defteri/hafızası) okur. “Hangi syscall çağrıldı? Argümanları ne?” sorularının cevabını burada bulur.
  2. Context Switch #2 (Tracer -> App): strace “Tamam, devam et” dedikten sonra, Kernel kontrolü tekrar esas programa verir ve syscall gerçekten çalışır (Örn: Diskten veri okunur).
  3. Exit Trap (Çıkış Yakalaması): İşlem biter bitmez program tekrar durdurulur. Program henüz sonucunu (örn: okunan veriyi) göremez.
  4. Context Switch #3 (App -> Tracer): İşlemci tekrar strace‘e döner. strace yapılan işin sonucunu Register’lardan okur ve ekrana basar.
  5. Context Switch #4 (Tracer -> App): Ve nihayet, kontrol son kez esas programa döner. Program kaldığı yerden hayatına devam eder.

Gördüğünüz gibi, tek bir basit işlem (bir harf okumak bile) için sıklıkla 2 veya daha fazla context switch yaşanabilir (mimariye ve kernel sürümüne göre değişir). Normalde nanosaniyeler/mikrosaniyeler süren bir işlem, bu sürekli “dur-kalk” trafiği yüzünden katlanarak yavaşlar.

Bu yüzden production ortamında strace kullanmak, otobanda giderken her 100 metrede bir el frenini çekip, arabadan inip, lastikleri kontrol edip tekrar binmeye benzer. Güvenlidir ama inanılmaz yavaştır.

sequenceDiagram
    autonumber
    participant App as Uygulama (Tracee)
    participant Kernel as Kernel
    participant Tracer as strace (Tracer)

    activate App 
    Note over App: Uygulama Çalışıyor...
    
    %% SYSCALL BAŞLANGICI
    App->>+Kernel: Syscall Çağrısı (Örn: read)
    deactivate App 
    
    rect
    Note right of Kernel: 🛑 ENTRY TRAP
    Note over Kernel, Tracer: ⚠️ Context Switch #1 (App -> Tracer)
    Kernel->>+Tracer: Sinyal (SIGTRAP): "Uygulama durdu!"
    
    Note over Tracer: Register'ları Oku (PTRACE_GETREGS)
    Tracer-->>-Kernel: "Tamam, devam et" (PTRACE_SYSCALL)
    
    Note over Kernel, App: ⚠️ Context Switch #2 (Tracer -> App)
    end

    %% ASIL İŞLEM (Bu arada strace bekliyor)
    %% Not: Burada görsel olarak App'in çalıştığını göstermek için 
    %% Kernel üzerinden tekrar App'i aktif ediyoruz.
    Kernel->>+App: Syscall'ı Gerçekten Çalıştır
    Note over App: Diskten okuma yapılır...
    App-->>-Kernel: İşlem Tamamlandı

    %% SYSCALL BİTİŞİ
    rect
    Note right of Kernel: 🛑 EXIT TRAP
    Note over Kernel, Tracer: ⚠️ Context Switch #3 (App -> Tracer)
    Kernel->>+Tracer: Sinyal (SIGTRAP): "İşlem bitti!"
    
    Note over Tracer: Sonucu Oku & Ekrana Yaz
    Tracer-->>-Kernel: "Tamam, devam et" (PTRACE_SYSCALL)

    Note over Kernel, App: ⚠️ Context Switch #4 (Tracer -> App)
    end

    Kernel-->>-App: Kontrolü Uygulamaya Ver
    activate App 
    Note over App: Kaldığı yerden devam eder...
    deactivate App 

ptrace Neden Bu Kadar Yavaş?

📉 Maliyet Hesabı

Normal trafik akışı şöyledir:

Program -> (hızla) -> Kernel -> (hızla) -> Donanım

Araya strace girdiğinde akış şuna döner:

1. Program Syscall yapar -> Kernel programı durdurur (SIGSTOP)
2. Kernel context değiştirir (Context Switch) -> strace
3. strace veriyi okur, ekrana yazar -> Kernel tekrar context değiştirir
4. Kernel programı devam ettirir (SIGCONT) … ve bu döngü saniyede binlerce kez tekrarlanır.

Sonuç? Sistemin tepki süresi (Latency), iş yükünün yoğunluğuna ve thread sayısına bağlı olarak %30 ile %500 arasında artabilir. 100ms’de yanıt veren API’niz, bir anda 3 saniyede yanıt vermeye başlar. Load Balancer’lar sunucuyu “ölü” (unhealthy) olarak işaretler ve trafik kesilir. Tebrikler, sadece loglara bakmak istemiştiniz ama tüm servisi çökerttiniz.

💡 Profesyonel Tavsiye: Production ortamında strace kullanacaksanız, asla doğrudan ana sürece (-p 1 veya Master Process) bağlanmayın. Sadece şüpheli olan tek bir thread’e veya worker process’e bağlanın. Ve işiniz biter bitmez (Ctrl+C) o parmağı oradan çekin.

😱 Gerçek Bir Korku Hikayesi: Cuma Günü Production Çöküşü

Bir e-ticaret sitesinde çalıştığınızı hayal edin. “Black Friday” yoğunluğu var. API sunucularından biri biraz yavaş yanıt veriyor (Latency artmış).

Saat 14:00: Kıdemli SysAdmin “Bir bakayım şuna” diyerek o sunucuya bağlanır. Sorunu anlamak için ana sürece strace -p 1 komutunu yapıştırır.

Saat 14:00:01:

• Sunucunun yanıt süresi 50ms’den 700ms’ye fırlar (ptrace overhead).
• Ön taraftaki Load Balancer, bu sunucunun “çok yavaş” olduğunu fark eder ve “Sunucu yanıt vermiyor” (Timeout) hatası alır.
• Load Balancer, başarısız olan istekleri diğer sunuculara dağıtmaya başlar (Retry Storm).
• Zaten yük altında olan diğer sunucular, gelen bu ani ekstra yükle ezilir ve onlar da yavaşlar.
• Zincirleme reaksiyon başlar. Tüm API kümesi (Cluster) domino taşı gibi çöker.

Saat 14:05: SysAdmin strace‘i kapatır ama iş işten geçmiştir. Sistem kendine gelene kadar binlerce dolarlık satış kaybedilmiştir.

Ders: Production ortamında strace kullanacaksanız, asla doğrudan ana sürece (-p 1 veya Master Process) bağlanmayın. Sadece şüpheli olan tek bir thread’e veya worker process’e bağlanın. Ve işiniz biter bitmez (Ctrl+C) o parmağı oradan çekin.

⚔️ 2. Tracing vs Sampling: İki Farklı Dünya

Linux performans analizinde iki temel yaklaşım vardır ve bunları karıştırmak felakete yol açabilir.

🔬 Tracing (İzleme) - strace

• Yöntem: “Her kareyi tek tek izlemek.”
• Maliyet: Çok Yüksek.
• Ne Zaman: “Bu program tam olarak neden hata veriyor?” dediğinizde.
• Analog: Bir güvenlik kamerasının 7/24 her saniyeyi kaydetmesi.

📷 Sampling (Örnekleme) - perf

• Yöntem: “Saniyede 99 kez rastgele fotoğraf çekmek.”
• Maliyet: Çok Düşük (%1-%2 overhead).
• Ne Zaman: “Sistem genelinde işlemciyi en çok kim yoruyor?” dediğinizde.
• Analog: Kalabalık bir meydana ara sıra bakıp “Genelde insanlar şu köşede birikmiş” demek.

Eğer sorununuz “Hata Ayıklama” (Debugging) ise strace; sorununuz “Hız Performansı” (Profiling) ise perf kullanın.

🌑 3. Neden Hiçbir Şey Göremiyorum? (Kör Noktalar)

En sinir bozucu senaryo: Program çalışıyor, fanlar son hız dönüyor (top çıktısında %100 CPU görüyorsunuz), ama strace çalıştırdığınızda ekran bomboş. İmleç öylece yanıp sönüyor.

strace bozuldu mu? Hayır. Sorun strace‘in baktığı yerde değil.

Önceki yazıdan “Restoran Analojisi”ni hatırlayın. strace sadece garsonu (syscalls) izler. Eğer müşteri (program), masasında oturmuş (CPU) ve kendi kendine derin düşüncelere dalmışsa (Logic/Matematiksel işlem), mutfaktan (Kernel) hiçbir şey istemez. Garsona seslenmez.

Bu durumda strace kördür.

⚖️ CPU-Bound vs I/O-Bound

• I/O Bound (Giriş/Çıkış Ağırlıklı): Program sürekli disk okur, ağa yazar. strace bayram eder, ekran akar.
• CPU Bound (İşlemci Ağırlıklı): Program matematiksel hesaplama yapar, veri şifreler (Encryption), video işler veya Sonsuz Döngüye (Infinite Loop) girmiştir.

🕵️‍♂️ Vaka Analizi: Sonsuz Döngü

Bir Python scriptiniz var ve kilitlendi:

🧪 Kendin Dene: CPU Canavarı Aşağıdaki kodu cpu_canavari.py olarak kaydedin ve çalıştırın.

# cpu_canavari.py
print("Sonsuz döngü başlıyor... Fan sesi için hazır olun!")
print("Durdurmak için: Ctrl+C")

while True:
    # CPU'yu %100 kullanan basit bir işlem
    2 + 2 

top ile baktığınızda %100 CPU yediğini göreceksiniz ama strace ile baktığınızda sessizlik hakim olacak.

Bu koda strace -p <PID> yaparsanız hiçbir çıktı alamazsınız. Çünkü bu döngü tamamen User Space (Kullanıcı Alanı) içinde gerçekleşir. Kernel’a bir iş düşmez. Diske yazmaz, ağa bağlanmaz.

💡 Peki, Ne Yapmalı?

Burada doğru araç strace değil, perf veya bir Debugger (gdb/pstack) dır.

perf, Linux’un performans analiz aracıdır. “Bu işlemci şu an hangi fonksiyonu çalıştırmakla meşgul?” sorusuna örnekleme (sampling) yaparak cevap verir.

# İşlemciyi en çok yoran fonksiyonları gör
sudo perf top -p <PID>

Çıktıda function_name veya kütüphane isimlerini gördüğünüzde “Ha, bu kod şu an JSON parse etmeye çalışırken takılmış” diyebilirsiniz.

🔒 4. Deadlock: “Çılgınlar Gibi Bekliyorum”

Bazen program CPU yemez (0% CPU), ama yanıt da vermez. strace yine bomboştur. Sanki zaman durmuştur. İşte buna Deadlock (Ölümcül Kilitlenme) denir.

🧠 Teknik Detay: Deadlock (Ölümcül Kilitlenme)

İki veya daha fazla işlemin, birbirlerinin elindeki kaynağı beklemesi ve bu yüzden sonsuza kadar durmasıdır.

• Analoji: Dar bir köprüde karşılaşan iki inatçı keçi. Biri geri gitmeden diğeri geçemez, ama ikisi de geri gitmez.
• Belirti: CPU kullanımı %0’dır ama program yanıt vermez.

Yazılım dünyasında bu şöyle olur:

• Thread A: Elinde Dosya X var, işini bitirmek için Dosya Y‘yi bekliyor.
• Thread B: Elinde Dosya Y var, işini bitirmek için Dosya X‘i bekliyor.

Sonuç? Sonsuz bekleyiş. Kernel’dan yeni bir istekte bulunmazlar çünkü sadece “bekliyorlardır”. Bu yüzden strace ekranında ya hiç hareket olmaz ya da sadece futex(..., FUTEX_WAIT, ...) (yani “uyuyorum”) mesajını görürsünüz.

graph TD
    ThreadA(Thread A)
    ThreadB(Thread B)
    ResourceX["Kaynağı X<br>(Örn: DB Tablosu)"]
    ResourceY["Kaynağı Y<br>(Örn: Dosya)"]

    ThreadA -- "Tuttu (Lock)" --> ResourceX
    ThreadB -- "Tuttu (Lock)" --> ResourceY
    
    ThreadA -.->|Bekliyor| ResourceY
    ThreadB -.->|Bekliyor| ResourceX

Bu durumda strace çaresizdir. Çözüm röntgeni değiştirmektir: pstack veya gdb ile thread’lerin Stack Trace‘ine (Yığın İzleme) bakmanız gerekir.

# Çalışan sürecin "zihin haritasını" (stack) dök
sudo pstack <PID>

Çıktıda pthread_mutex_lock gibi fonksiyonlarda bekleyen thread’ler görürseniz, tebrikler, bir deadlock yakaladınız.

🎭 5. strace’in Sizi Kandırdığı Anlar

Bazen strace çıktısı size gerçeği söylemez. Daha doğrusu, gerçeğin tamamını söylemez.

📦 A. Userspace Buffering (Tamponlama)

Kodunuzda printf("Merhaba") yazdınız ama strace çıktısında write göremiyorsunuz. Neden? Çünkü C kütüphanesi (glibc), verimlilik için o “Merhaba”yı hemen çekirdeğe göndermez. Kendi hafızasında (buffer) biriktirir ve yeterince veri birikince topluca gönderir. Siz o sırada “Neden yazmıyor bu!” diye saçınızı başınızı yolarsınız.

☕ B. JIT Dilleri (Java, Node.js, Go)

Derlenen dillerde (C/C++) semboller nettir. Ancak Java veya Node.js gibi dillerde, fonksiyon isimleri yerine 0x7f34a... gibi anlamsız bellek adresleri görürsünüz. Bu diller kodlarını çalışma anında (Just-In-Time) derledikleri için, standart strace bu dinamik yapıları çözmekte zorlanır.

⚡ C. Asenkron I/O (Async)

Modern uygulamalar (Nginx, Node.js), epoll veya io_uring gibi asenkron yöntemler kullanır. Bu ne demek? Program “Dosyayı oku” der (read) ve cevabı beklemeden başka işe geçer. Cevap hazır olduğunda Kernel ona haber verir. strace ile baktığınızda, işlemin başladığını görürsünüz ama bittiği yer bambaşka bir satırda olabilir. Takibi zordur.

👻 D. Görünmez Syscall’lar (vDSO)

Bazı sistem çağrıları (örn: gettimeofday - saati sorma veya getcpu) o kadar sık kullanılır ki, Kernel her seferinde context switch yapmamak için bunları “User Space” içine özel bir alan (vDSO) olarak kopyalar.

🧠 Teknik Detay: vDSO (Virtual Dynamic Shared Object)

Kernel’ın bazı işlevlerini (örn: saat okuma) hızlandırmak için Kullanıcı Alanına (User Space) ışınladığı küçük bir kütüphanedir.

• Neden? Saati sormak için Kernel’a gitmek (Context Switch) çok pahalıdır.
• strace Neden Görmez? İşlem Kernel’a gitmeden, kendi hafızasında bittiği için.

Program saati sorduğunda, aslında Kernel’a gitmez, kendi hafızasındaki kopyadan okur. Sonuç: Program deli gibi saat soruyordur, çalışıyordur ama strace ekranı bomboştur.

🗺️ E. Hayalet Okumalar (mmap)

Veritabanları (PostgreSQL, MongoDB) genellikle dosyaları klasik read ile okumaz, mmap ile hafızaya haritalar. Bu durumda dosya sanki RAM’in bir parçasıymış gibi erişilir.

🧠 Teknik Detay: mmap (Memory Mapped File)

Bir dosyayı sanki hafızadaki bir dizi (array) gibi okumayı sağlayan yöntemdir.

• Farkı: read() gibi Kernel’dan sürekli veri istemezsiniz. Dosya sanal hafızaya “yapıştırılır”.
• strace Neden Görmez? Dosya okumaları artık birer “bellek erişimi” (memory access) olmuştur, syscall değildir.

strace sadece ilk mmap çağrısını görür; sonrasındaki gigabyte’larca veri okumasını göremez. Veri akıyor, sayfa çevriliyor ama garsonun haberi yok.

💡 İpucu: lsof vs strace

• lsof: Şu an HALİHAZIRDA açık olan dosyaları listeler. “Hangi dosya açık?” sorusunu cevaplar.
• strace: Dosyanın NEDEN açılamadığını gösterir. “Program dosyayı açarken hangi hatayı alıyor?” sorusunu cevaplar. Önce lsof ile bakın, dosya yoksa veya açılamıyorsa strace ile nedenine inin.

⚖️ 6. Denge: strace Hâlâ Ne Zaman Kral?

Bu kadar risk ve sınırlamaya rağmen strace neden hâlâ her sistemcinin ilk aşkıdır?

1. Evrenseldir: En küçüğünden en büyüğüne her Linux dağıtımında bulunur. Kurulum gerektirmez.
2. Basittir: Karmaşık scriptler yazmanıza gerek yoktur. Tek komutla çalışır.
3. Hatasızdır: Kernel yalan söylemez. Log dosyaları manipüle edilebilir, ama syscall’lar gerçektir.

Eğer “eski usul” bir monolitik uygulamanız varsa veya basit bir scripti debug ediyorsanız, strace hâlâ en hızlı çözümdür.

🚀 7. Evrimsel Sıçrama: Cerrah Bıçağından Nanoteknolojiye (eBPF)

strace‘in yavaşlığından ve sınırlı görüş alanından bahsettik. Peki teknoloji burada tıkandı mı? Elbette hayır.

Modern Linux sistemlerinde (Kernel 4.x+), eBPF (extended Berkeley Packet Filter) denen bir devrim yaşanıyor.

🐝 eBPF Nedir?

strace, programı sürekli durdurup “Ne yapıyorsun?” diye soran bir trafik polisi gibidir. eBPF ise yollara yerleştirilmiş akıllı kameralardır. Trafiği (programı) asla durdurmaz, sadece geçen veriyi kaydeder.

Bu sayede:

1. Sıfıra yakın performans kaybı ile production’da güvenle çalışır.
2. Sadece Syscall’ları değil, User Space fonksiyonlarını (Java, Go, Python methodları) bile izleyebilir.

🗺️ Hangi Durumda Hangi Araç?

Kafanız karışmasın, işte size basit bir karar matrisi:

Belirti	Olası Sorun	İlk Bakılacak Araç
Hata Mesajı Var / Çöküyor	Dosya, Ağ, Yetki Hatası	✅ strace
%100 CPU Kullanımı	Sonsuz Döngü, Ağır Hesaplama	✅ perf veya top
%0 CPU ama Yanıt Yok	Deadlock (Kilitlenme), Ağ Beklemesi	✅ strace (Ağ ise) / pstack (Kilit ise)
User Space Loop (Loglar eksik)	Tamponlama (Buffering) Sorunu	✅ ltrace (Kullanıcı alanı izleme) veya strace -e write=1
Production Yavaşlığı	Latency Analizi, Canlı İzleme	✅ eBPF (syscount, funclatency)

flowchart TD
    Start("Bir Sorun Var!") --> CPU{"CPU Durumu?"}
    
    CPU -- "%100 CPU" --> Profiling["Profiling"]
    Profiling --> Perf["perf / top"]
    
    CPU -- "%0 CPU (Bekliyor)" --> Wait{"Neyi Bekliyor?"}
    
    Wait -- "Dosya/Ağ" --> Trace["Tracing"]
    Trace --> Strace["strace"]
    
    Wait -- "Kilit (Deadlock)" --> Stack["Stack Trace"]
    Stack --> Pstack["pstack / gdb"]
    
    CPU -- "Normal ama Hata Var" --> Error{"Hata Türü?"}
    Error -- "Syscall Hatası" --> Strace
    Error -- "Mantık Hatası" --> Debug["Debugger"]
    Debug --> GDB["gdb / ltrace"]
    
    CPU -- "Production Yavaşlığı" --> Prod["Non-Intrusive"]
    Prod --> Ebpf["eBPF / syscount"]
    
    style Strace stroke:#f96,stroke-width:2px,color:#fff,stroke-dasharray: 5 5
    style Perf stroke:#f96,stroke-width:2px,color:#fff,stroke-dasharray: 5 5
    style Ebpf stroke:#4caf50,stroke-width:4px,color:#2e7d32,stroke-dasharray: 5 5

🔮 Bir Sonraki Adım: “Dosya Orada Ama Yok!”

strace ve perf ile performans sorunlarını ve gizli hataları avlamayı öğrendik. Artık elinizde bir İsviçre Çakısı var.

Ancak bazen düşman göründüğünden daha kurnazdır.

Hiç “Dosya orada, izinleri 777, ben root kullanıcısıyım ama yine de Permission Denied alıyorum!” diye saçınızı başınızı yolduğunuz oldu mu? Veya Docker içinde “Dosya yok” hatası alıp, ls ile baktığınızda dosyayı orada gördüğünüz?

Bir sonraki yazıda, Linux dosya sisteminin (VFS) karanlık dehlizlerine dalacağız. Inode’lar, Namespace’ler ve “Konteyner İlüzyonları” arasında kaybolan dosyaların peşine düşeceğiz.

🚀 Serinin Devam Yazısı: Linux’ta Dosya ve Yetki Problemlerini Kernel Seviyesinde Anlamak