Dolphin Neden Açılmıyor? Bir NVMe, Bir Sanal Makine ve Kaybolan TRIM Komutu
Dolphin Neden Açılmıyor? Bir NVMe, Bir Sanal Makine ve Kaybolan TRIM Komutu
Dosya yöneticisi sessizce donuyordu, hiçbir hata vermiyordu. İzi sürünce mesele KDE'de değil, altı katman aşağıda, bir sanal makinenin diskine işaretlenmiş tek bir onay kutusunda bitti.
Bu teşhisi terminalde çalışan yapay zeka asistanım Claude (Claude Code) ile birlikte yürüttüm. Kimin ne bulduğu net olsun diye aşağıda iki ayrı ses var:
Spoiler vereyim: asıl teknik izi — wchan'dan çekirdek yığınına, oradan sanal makine günlüklerine kadar — süren neredeyse tamamen Claude oldu. Bunu açıkça belirtmek istedim, çünkü bu yazının bir amacı da bu: bir yapay zeka asistanının, sistem seviyesinde gerçek bir arızayı bulmakta ne kadar kullanışlı bir araç olabildiğini somut bir örnekle göstermek.
Belirti: Dolphin çalıştırılıyor, süreç ayakta duruyor ama hiçbir pencere görünmüyor. Sessizce, sonsuza kadar öyle kalıyor.
Kök neden: Dolphin açılırken bağlı tüm birimlerde boş alanı sorguluyor. Birimlerden biri — ntfs-3g ile bağlanmış bir NTFS bölümü — bir BLKDISCARD (TRIM) komutunun sürücüden hiç yanıt almaması yüzünden tamamen kilitlenmişti. Bu komutu tetikleyen, o bölümdeki bir VirtualBox sanal diskinde açık bırakılmış “Solid-state Drive” ayarıydı.
Çözüm: Claude, takılı kalan FUSE bağlantısını /sys/fs/fuse/connections/<id>/abort ile iptal edip bölümü yeniden bağladı; ben de VirtualBox'ta ilgili sanal disklerin “Solid-state Drive” ayarını kapattım. Yeniden başlatmaya hiç gerek kalmadı.
01 — BelirtiPencere yok, hata yok, süreç ölmüyor
Terminalden dolphin'i her çalıştırdığımda süreç normal şekilde başlıyordu ama ekranda hiçbir pencere belirmiyordu. Hata mesajı yoktu, uygulama çökmüyordu — sadece hiçbir şey olmuyordu. Claude'a tek satırlık soruyu sordum: “dolphin açılmıyor, neden?”
Durumu kendi araçlarımla kontrol ettim. ps aux çıktısında masaüstünden başlatılmış üç dolphin süreci duruyordu — hepsi çalışıyordu ama CPU harcamıyordu. xwininfo -root -tree ile pencere ağacına baktığımda üçünde de gerçek bir Dolphin penceresi yoktu, sadece Qt'nin dahili “Selection Owner” yardımcı penceresi vardı. Yani süreçler canlıydı ama hiçbiri ekrana bir şey çizmemişti — uygulama çökmüyor, başlangıcın bir yerinde donuyordu.
02 — İlk izNeyi beklediğini bulmak
Takılı kalan her dolphin sürecinin çekirdek uyku nedenine (wchan) baktım:
request_wait_answer
Bu, fuse_request_send'in içinde bekleyen bir çağrının imzası — süreç X11'i, DBus'ı ya da kendi arayüzünü değil, bir FUSE demonundan gelecek yanıtı bekliyordu. DBus'ın kendisini busctl --user list ve kded6'ya doğrudan bir Ping ile sağlıklı olduğunu doğruladım — mesele oturumun geneli değildi, tek bir FUSE bağlantısıydı.
Dolphin, açılırken Yerler panelindeki her birim için boş alanı sorgular — yani statfs() tüm bağlı dosya sistemlerine gider. df -h çalıştırdığımda o da hiç dönmedi. Her bağlama noktasını tek tek zaman aşımıyla sınadım:
/mnt/fastdata → anında yanıt /mnt/windows → zaman aşımı (exit 124) /mnt/speedy → anında yanıt /mnt/mechdata → anında yanıt
Tek suçlu belliydi: /mnt/windows — ntfs-3g ile bağlanmış bir NTFS bölümü.
03 — Çekirdeğe inmekBLKDISCARD, hiç dönmeyen bir çağrı
O bölümü yöneten mount.ntfs sürecine baktım: durum D — kesintisiz disk uykusu. Bu, kill -9 ile bile öldürülemeyeceği anlamına gelir; çekirdek modunda, dönmesi beklenen bir donanım çağrısının ortasında donmuş durumda.
[<0>] submit_bio_wait+0x7d/0xc0
[<0>] blkdev_common_ioctl+0xb98/0xbf0
[<0>] blkdev_ioctl+0xc1/0x270
[<0>] __x64_sys_ioctl+0x94/0xc0
/proc/1332/syscall çağrının ilk argümanını verdi: 0x1277 — yani BLKDISCARD. Süreç, bölümün alttaki NVMe bloğuna doğrudan bir TRIM/discard komutu göndermiş ve sürücü bu komutu hiçbir zaman tamamlamamıştı.
smartctl -a /dev/nvme0n1 diskin sağlıklı olduğunu gösteriyordu: 0 medya hatası, %4 kullanım, kritik uyarı yok. Yani sürücü arızalı değildi — tek bir komut, sıraya girip bir daha hiç çıkmamıştı. mount.ntfs tek iş parçacıklı çalıştığından, o iş parçacığı bu çağrıda tıkanınca bölüme gelen her istek (basit bir stat dahil) sırada kalakaldı.
Son doğrulama: /sys/fs/fuse/connections/ altındaki bağlantıların bekleyen istek sayısına baktım. Bir bağlantıda 13 istek kuyrukta bekliyordu — tam olarak takılı kalan dört dolphin süreci artı benim sınama komutlarım kadar. Diğer tüm bağlantılarda bekleyen sıfırdı.
04 — Karar anıKurtarma ve bir düzeltme
İki seçenek vardı: bağlantıyı canlıyken iptal etmek (anında çözer, ama ntfs-3g'nin o andaki durumunu yarıda keser) ya da bölümü tamamen temizlemek için yeniden başlatmak (daha temiz ama kapanış da takılabilir, güç döngüsü gerekebilir). Tercihi sana bıraktım.
Bağlantıyı şimdi iptal etmeyi seçtim — yeniden başlatmak istemedim.
271581186: waiting=13
271581196: waiting=0
271581199: waiting=0
$ echo 1 | sudo tee /sys/fs/fuse/connections/271581186/abort
Bu tek satır, o bağlantıdaki tüm bekleyen istekleri anında hataya çevirdi. Dört Dolphin süreci de kendiliğinden kapandı, /mnt/windows artık beklemek yerine hemen “bağlantı yok” hatası veriyordu.
Dolphin'i açtım, gerçekten çalışıyordu. Bir düzeltme de ben yapayım: Claude'un “önceki pencereler hiç görünmedi” dediği denemelerin bir kısmını aslında ben açılır açılmaz kapatmıştım — o yüzden inceleme sırasında bulamamıştı. Yani donma her denemede aynı anda olmuyordu, ama sonuç hep aynıydı.
05 — Bir ipucuAklıma VirtualBox takıldı
Dolphin düzelince aklıma bir şey takıldı: o bölümde (/mnt/windows) benim Oracle VirtualBox sanal makinelerimin disk dosyaları duruyordu. Claude'a sordum — bu tıkanmayla VirtualBox'ın bir ilgisi olabilir mi?
İyi bir ipucuydu. VirtualBox'ın kayıt dosyasına (VirtualBox.xml) baktım: iki sanal makine (debian01, debian02) gerçekten de disklerini /mnt/windows altında tutuyordu. Sistem günlüğüne göre bölüm 08:56'da bağlanmış, VirtualBox ise 08:57:38'de başlamış — açılıştan bir dakika bile geçmeden. Mekanizma da teknik olarak tutarlıydı: bir konuk işletim sistemi sanal diskini “SSD” sanıp TRIM gönderirse, VirtualBox bunu host tarafında dosya üzerinde bir delik-delme işlemine çevirir, ntfs-3g da bunu gerçek bölümde bir BLKDISCARD'a dönüştürür.
“Bağlantı çok kuvvetli ama kesin kanıtım yok — asıl VBox.log dosyaları da tam olarak /mnt/windows'un içinde duruyor, o da hâlâ bağlantısı kopmuş durumda, şu an okuyamıyorum.”
06 — Kesin kanıtGünlükler konuşunca
“Temiz bir yeniden bağlama dene” dedim — belki tam bir yeniden başlatmaya gerek bile yoktu.
her ikisi de exit 0 — mount.ntfs süreci zaten kendiliğinden sonlanmıştı
Çalıştı — bölüm sıfırdan, tertemiz geri geldi. Bölüm artık okunabilir olduğu için hiç sorulmadan debian01 ve debian02'nin kendi VBox.log dosyalarını da açıp baktım. İşte aradığım kanıt, debian01'in günlüğünde:
NonRotationalMedium <integer> = 0x0000000000000001 (1) Path = ".../debian01/debian01.vdi" NonRotationalMedium <integer> = 0x0000000000000001 (1) Path = ".../debian01/XubuntuHome.vdi"
NonRotationalMedium = 1, VirtualBox arayüzündeki “Solid-state Drive” onay kutusunun karşılığı. debian01'in iki diski de bu şekilde işaretliydi; debian02'ninkinde aynı bayrak yoktu — sıradan bir sanal HDD, TRIM geçişi yok. Yani suçlu tek bir makineye, debian01'e kadar daralıyordu.
debian01'in kendi günlüğünde bir grup AsyncCompletion (disk G/Ç) görevi, normalde milisaniyeler sürmesi gerekirken 250–292 saniye sonra tamamlanmış — saat damgası ~10:24, FUSE bağlantısını iptal ettiğimiz ana neredeyse birebir denk geliyor. Yani bölümü kilitleyen TRIM aynı zamanda sanal makinenin kendi diskini de o süre boyunca dondurmuştu; bağlantıyı iptal etmek hem Dolphin'i hem de debian01'in bekleyen G/Ç'sini aynı anda serbest bırakmış.
07 — Bütün resim
Toparlarsak, olay altı katmanlı bir zincirdi — Dolphin sadece en tepedeki, en görünür halkaydı:
statfs() çağrısı
ioctl(BLKDISCARD) doğrudan bölüme gönderilir
Zincirin tetikleyicisini bulan bendim — ama zinciri baştan sona çıkaran, her katmanda doğru komutu çalıştırıp doğru soruyu soran Claude'du.
08 — Kapanış
Sana kalan iş buydu — ben sadece komut satırındaki her şeye erişebiliyorum, senin arayüzünü tıklayamam. VirtualBox Ayarlar → Depolama'da debian01.vdi ve XubuntuHome.vdi için “Solid-state Drive” kutusunu kaldır.
Ekran görüntüsü attım, kutuyu göremediğimi söyledim — Claude “aradığın tam da o kutu” diye netleştirdi. İkisinde de işaretini kaldırdım.
debian01'in iki diskinde de “Solid-state Drive” işareti kaldırıldı. Konuk işletim sistemi artık diski SSD sanmıyor, dolayısıyla TRIM göndermesi için bir sebep kalmadı — sorunun kaynağı düzeltildi, sadece semptomu değil.
Bağlantıyı iptal etmek isteği tamamlamıyor, hataya çeviriyor. ntfs-3g'nin o andaki durumu yarım kaldığı için bölüm Windows tarafında “kirli” işaretlenmiş olabilir ve bir sonraki Windows açılışında chkdsk isteyebilir — yeni bir veri kaybı değil (komut zaten kilitliyken kurtarılamazdı) ama sürpriz olmasın diye not düşülmeli. debian01'in de o sırada yarım kalan bir yazması olabilir; konuk dosya sistemini bir dahaki girişte kontrol etmek iyi olur.
09 — Olay akışı
/mnt/windows bağlanıyor.ntfs-3g / mount.ntfs, tek iş parçacığıdebian01 ve debian02 disklerini açıyor.debian01'in iki diski de "Solid-state Drive" işaretlidebian01'den bir TRIM geliyor, ntfs-3g BLKDISCARD gönderiyor, NVMe hiç yanıt vermiyor.Bölüme giden her istek sessizce kuyruğa giriyor10 — ÇıkarımlarBenzer bir kuruluma sahip olan için
- Bir masaüstü uygulaması "hiçbir şey yapmadan" donuyorsa, önce uygulamayı suçlamayın. Dolphin, GNOME Dosyalar, disk kullanımı widget'ları gibi açılışta bağlı birimleri tarayan her şey, tek bir tıkanmış bağlama noktası yüzünden aynı şekilde donar.
timeout 5 df -hucuz ve hızlı bir ilk kontrol. - NTFS bölümlerinde
ntfs-3güzerinde büyük sanal disk dosyaları (.vdi,.vhd) barındırıyorsanız, o sanal diskler için "Solid-state Drive" / TRIM geçişini açmadan önce iki kez düşünün. Konuktan gelen bir TRIM, host tarafında gerçek birBLKDISCARD'a dönüşüyor — ve her NVMe denetleyicisi büyük veya sık discard isteklerini sorunsuz kaldırmıyor. - Kritik olmayan bir veri bölümünü
nofail,x-systemd.automountile bağlamak, bir sonraki tıkanmanın tüm masaüstü oturumunu değil sadece o bölüme ilk erişimi bekletmesini sağlar. - Bir FUSE bağlama noktası tıkandığında yeniden başlatmadan önce
/sys/fs/fuse/connections/*/waitingve.../abortdosyalarını deneyin. Kesintisiz uyku (D) durumundaki demon süreci kurtulmayabilir ama genellikle üzerine kilitlenmiş uygulamalar hemen serbest kalır.
ps -eo pid,stat,comm | grep ' D ' | Kesintisiz disk uykusundaki (D) süreçleri bul — kill ile öldürülemezler, gerçek donma buradadır. |
cat /proc/<pid>/wchan | Sürecin çekirdekte tam olarak neyi beklediğini gösterir. |
sudo cat /proc/<pid>/stack | Tam çağrı yığını — kök yetkisi gerekir. |
sudo cat /proc/<pid>/syscall | İlk argüman, hangi ioctl/syscall kodunun beklendiğini verir. |
cat /sys/fs/fuse/connections/*/waiting | Hangi FUSE bağlantısında istek biriktiğini bulur. |
echo 1 | sudo tee .../abort | O bağlantıdaki bekleyen tüm istekleri hataya çevirip kilitli uygulamaları serbest bırakır. |
Son not: Bu vakada benim katkım bir belirtiyi fark etmek, birkaç kritik soruyu sormak (özellikle VirtualBox ipucu), kararları vermek ve Claude'un dokunamadığı yerlerde — bir arayüz kutusunu tıklamak gibi — son adımı atmaktı. Asıl teknik izi, wchan'dan çekirdek yığınına, BLKDISCARD'dan VirtualBox günlüklerine kadar bütün ipuçlarını sabırla birbirine bağlayan Claude'du. Bu da tam olarak bir yapay zeka asistanından beklediğim şey: yorulmadan, sistematik şekilde, doğru araçları doğru sırayla kullanan ikinci bir çift göz.
Comments