Geri yüklenemeyecek kadar dolu bir disk

 (sixcolors.com)
2 puan yazan GN⁺ 2024-04-05 | 1 yorum | WhatsApp'ta paylaş
  • M2 MacBook Pro’nun başlangıç birimi, Steam oyunları indirilirken yalnızca 41 KB boş kalacak kadar doldu ve macOS dosya silmeyi bile yapamaz hale geldi
  • Finder’da çöp kutusunu boşaltma, Terminal’de rm ve find -exec rm, Disk Utility’de Time Machine anlık görüntülerini silme dahil her şey “No space left on device” türü hatalarla başarısız oldu
  • Yeniden başlatmanın ardından önyükleme de yarıda takıldı; recoveryOS ve Apple silicon’un Share Disk özelliğiyle başka bir Mac’e bağlansa bile silme işlemi zorla gerçekleştirilemedi
  • Sürücüyü sıfırlayıp macOS’i yeniden kurduktan sonra Time Machine geri yüklemesi denendi ancak Ventura’daki geri yükleme yarıda kaldı; Sonoma 14.4 ile önceki 14.3.1 arasındaki sürüm farkı ve SMB/Samba ağ bağlama hataları da peş peşe geldi
  • Sonunda en güncel Time Machine disk imajı harici 1 TB SSD’ye kopyalanarak ev dizini dosyaları ve uygulamalar elle kurtarıldı; depolama alanı tükenmesi ile yedekten geri yükleme başarısızlığı bir araya gelince deneyimli kullanıcılar için bile başa çıkmak zor olabiliyor

Silmenin bile engellendiği, depolama alanı tükenmiş Mac

  • M2 MacBook Pro’nun depolama alanı, Steam’den yasal olarak satın alınmış bir oyunu indirirken tamamen doldu
  • macOS, sürücü tehlikeli derecede dolmasına rağmen büyük Steam indirmesini durdurmadı ve başlangıç biriminde yalnızca 41 KB kaldı
  • Önemli dosyaların çoğu buluttaydı ve yereldeki büyük dosyaları mutlaka korumak gereken bir durum yoktu
  • Sorun yalnızca basit bir alan yetersizliği değil, işletim sisteminin hiçbir yolla dosya silemediği bir duruma dönüşmesiydi

Şüphelenilen neden: Steam indirmesi ve yerel Time Machine anlık görüntüleri

  • Gigabit internet bağlantısı ve büyük Steam dosyaları nedeniyle macOS’in depolama artışını denetleyememiş olması mümkün
  • Aynı anda macOS’in yerel Time Machine anlık görüntüleri oluşturuyor olması da şüpheliydi
  • macOS, harici veya ağdaki bir Time Machine hedefine yedek alırken bile son 24 saatin yerel yedeklerini sunmak için anlık görüntüler tutar
  • Steam dosyaları dışarıdan tek, dev bir dosya gibi görünse de Time Machine açısından farklı ele alınmış olabilir
  • Yereldeki gerçek dosya ile özel olarak oluşturulan anlık görüntüler çakışmış olabilir, ancak kesin neden belirlenemedi

Başarısız olan tüm silme girişimleri

  • Finder’da çöp kutusunu boşaltma işlemi File > Empty Trash üzerinden başarısız oldu
    • Hata mesajı “The operation can’t be completed because the disk is full” idi
  • Terminal açıldı ama standart Unix rm komutu çalışmadı
    • Hata mesajı “No space left on device” idi
    • Büyük dosyaları bulup ardından -exec seçeneğiyle rm çalıştıran find tabanlı alternatif de başarısız oldu
  • Disk Utility içinde de APFS başlangıç birimindeki Time Machine anlık görüntüleri seçilip silinmeye çalışıldı ama aynı sınıra takıldı
    • Normalde anlık görüntüler, yalnızca önceki anlık görüntüye göre fark kadar alan kaplar
    • Bu durumda da “no space left” hatası oluştu

Yeniden başlatma, recoveryOS ve Share Disk de işe yaramadı

  • Önbellek temizliği umuduyla yeniden başlatıldı ama Mac artık normal şekilde açılmadı
  • İlerleme çubuğu yaklaşık yarıya geldikten sonra başarısız olma durumu tekrarlandı
  • recoveryOS içinde başlangıç birimi bağlı değilken Disk Utility onarımı ve yeniden kurulumla ilgili işlemler denendi, ancak Terminal komutları aynı hatayı verdi
  • Apple silicon’daki Share Disk özelliğiyle ilgili sürücü başka bir Mac’e bağlanmaya çalışıldı
    • Samba tabanlı disk paylaşımı üzerinden silmeyi zorlamak istendi, ancak başarısız oldu

Time Machine geri yüklemesi sırasında devam eden sorunlar

  • Önceki akşamın yedeğini içeren Time Machine yedekleri vardı ve önemli verilerin çoğu bulutta olduğu için tam kurtarmaya aşırı takıntılı olunan bir durum değildi
  • Önce sürücü silinip macOS Recovery ile MacBook Pro’nun kutudan çıktığındaki varsayılan sistemi olan Ventura yeniden kuruldu
  • macOS başlarken Migration Assistant ile ağdaki Time Machine yedeğine erişildi ve yeterli boş alan bırakmak için bazı geri yükleme öğelerinin seçimi kaldırıldı
  • Geri yükleme sırasında Ventura yarıda takıldı ve sonrasında devam etmedi
  • Ardından Mac, o sırada kullanılan macOS sürümü olan Sonoma’ya yükseltildi
    • Yükseltme başarılı oldu ama kurulan sürüm 14.4’tü
    • Eski Mac’te 14.3.1 kurulu durumdaydı
    • Başlangıç aşamasında doğrudan geri yükleme denenince sürüm farkı nedeniyle buna izin verilmedi

Sonoma 14.4’te ağ üzerinden Time Machine bağlama sorunu

  • Varsayılan bir Sonoma kullanıcı hesabı oluşturulduktan sonra Migration Assistant çalıştırıldı
  • Migration Assistant, Time Machine yedeğini yöneten ağdaki Mac’i bulup tanıdı
  • Ancak çocuğun yedekleme birimini bağlayamadı ve tekrar tekrar “Mount failed” mesajı gösterildi
  • Forum aramalarına göre, Sonoma’da SMB/Samba tabanlı ağ bağlama süreci Time Machine geri yüklemesinde bozulmuş durumdaydı ve bir çözüm bulunamamıştı
  • Bu sorunun macOS 14.4’te de hâlâ geçerli olduğu görülüyordu

Son kurtarma yöntemi: yedeği harici SSD’ye kopyalayıp elle taşıma

  • Tam bir Migration Assistant geri yüklemesinden vazgeçildi ve yalnızca gerekli uygulamalar ile dosyalar elle geri getirildi
  • Ağ yedeğini yöneten Mac’te ilgili bilgisayarın disk imajına çift tıklanıp Time Machine birim parolası girildi
    • Ağdaki Time Machine birimi için zaten her zaman ayrı bir parola ayarlanmıştı
  • En güncel zaman damgasını taşıyan disk simgesi bulunup boş bir harici 1 TB SSD üzerine kopyalandı
  • Harici SSD, MacBook Pro’daki geçici hesaba bağlanarak gerekli dosyalar aktarıldı
    • Ev dizini klasörlerinin içeriğinin büyük bölümü buna dahildi
    • Büyük indirme dosyaları ve gereksiz bazı video dosyaları hariç tutuldu
  • Harici SSD, eksik dosyalar ortaya çıkarsa ek kurtarma yapılabilmesi için bir süre saklanacak

Denenemeyen alternatifler

  • Ağ yedeklemesi için kullanılan Time Machine sürücüsü, yedeği yöneten Mac’ten çıkarılıp çocuğun Mac’ine doğrudan bağlanabilirdi
    • Bu durumda Migration Assistant’ın başlangıç noktası olarak görünmüş olması mümkündü
  • Bağlı Time Machine disk imajındaki sanal disk kopyalanarak harici 1 TB SSD’nin bir Mac kaynak birimi gibi görünmesi de sağlanabilirdi
    • Bu yöntemin gerçekten işe yarayıp yaramayacağı doğrulanmadı
    • Başarılı olsaydı, doğrudan Migration Assistant ile geri yükleme mümkün olabilirdi
  • Ancak zaten saatler süren çalışma ve bir günden uzun denemeler birikmişti; kullanıcı da kusursuz klasör düzeyinde bir kurtarmayı çok istemediği için ek deneyler yapılmadı

İlgili okumalar

1 yorum

 
GN⁺ 2024-04-05
Hacker News yorumları

  • Yazar, Mac’i harici bir depolama aygıtından başlattıktan sonra dahili diskteki gereksiz dosyaları silseydi daha iyi olabilirdi: Use an external storage device as a Mac startup disk
    Apple Silicon tabanlı Mac’lerde harici önyükleme sırasında tüm portların eşit olmaması şaşırtıcıydı.
    macOS’i bir depolama aygıtına kurarken Mac dizüstülerde sol taraftaki portlar içinden en soldaki USB-C portundan kaçınmak gerekiyor; iMac/Mac mini/Mac Studio/Mac Pro’da da modele göre kaçınılması gereken ayrı USB-C portları var.
    Kurulum bittikten sonra ise herhangi bir porta takılabileceği söyleniyor.

    • Önerilenle fiilen aynı şeyi zaten denemiş.
      Yazar, ayrı bir bölüm olan recoveryOS ile önyükleme yaptıktan sonra ana sistem bölümünden dosya silmeye çalışmış, ancak rm aynı No space left on device hatasıyla başarısız olmuş.
      Bu yüzden başkalarının söylediği gibi echo -n >file ile dosyayı kırpma yöntemi çalışmış olabilir.
    • Dosya sisteminin kendisi kilitlenme durumuna düştüyse, nereden önyükleme yaparsanız yapın dosya sistemi sürücüsü üzerinden dosya silme yöntemi işe yaramaz.
    • recoveryOS veya Mac Share Disk/Target Disk modu da işe yaramamışken, bu yöntemin neden işe yarayacağını düşündüklerini merak ediyorum.
    • Böyle bir yorum, 8 yıl sonra o döneme göre eski bir Mac’in sorununu çözmek için arama yapan biri için gerçekten sevindirici olurdu.
    • Mac dizüstülerde önyüklenebilir bir OS oluştururken neden ilk USB-C portunun kullanılmaması gerektiğini bilen var mı merak ediyorum.

  • HFS+ disk yapısı hakkında az biraz bilgiyle tahmin yürütürsek, journal dosyası da dolmuş ve silme işlemi journal’a yazmayı, bazı durumlarda da genişletmeyi gerektirdiği için, silmenin kendisi geçici de olsa daha fazla alan isteyen tuhaf bir duruma düşmüş gibi görünüyor.
    macOS, sürücüde yalnızca 41KB kalana kadar dosya yazmaya devam etmiş.
    NTFS ve FAT32’yi yanlışlıkla 0 bayta kadar doldurduğum olmuştu; o zaman bile bir şeyleri silmek mümkündü.
    Forumları karıştırınca Sonoma’nın Time Machine geri yüklemesi için SMB/Samba tabanlı ağ bağlama prosedürünü bozduğu, 14.4’te de hâlâ bir çözüm olmadığı anlaşılıyor.
    Deneyimlerime göre SMB, 10.12~10.13 civarından beri güvenilmesi zor ve fazlasıyla hatalı hale geldi; artık Apple bunun çalışıp çalışmadığını bile umursamıyor gibi görünüyor.
    On yıllarca Mac deneyimi olmayan insanların böyle zincirleme sistem arızalarıyla karşılaşınca ne yapacağını hayal etmek istemiyorum.
    On yıllarca Mac deneyimim yok ama böyle bir durumda önce fsck denemeyi düşünürdüm; burada bundan bahsedilmemiş olması tuhaf.
    Disk içeriğini başka bir diske kopyalayıp biçimlendirdikten sonra geri koymak mümkün değilse, APFS belgelerine (https://developer.apple.com/support/downloads/Apple-File-System-Reference.pdf) bakıp dd ve bir onaltılık düzenleyiciyle boş alan yaratmak için nereyi düzeltmek gerektiğini bulmaya çalışırdım.

    • Bu, journaling dosya sistemleri için geçerli; yazarken kopyalama (CoW) dosya sistemlerinde ise her değişiklik yeni bir dosya ağacı oluşturup kökün o yeni ağacı göstermesiyle yapılır.
      Daha sonra çöp toplama, artık aktif ağaca ait olmayan dosyaları bulup depolama alanına geri kazandırır.
      Genelde ağaçtaki değişiklik miktarını yönetilebilir düzeyde tutmak için değişiklikler toplu işlenir; bu tasarım sayesinde dosya sistemi snapshot’ları da belirli bir ağaca yönelik başka bir referans haline gelir.
      Bu süreç alan gerektirir, ancak CoW dosya sistemleri genellikle bu nedenle acil durum depolama alanını ayrıca ayırır.
    • Apple, Samba GPLv3’ü benimsedikten uzun süre önce kendi uygulamasına geçti: https://lists.samba.org/archive/samba-announce/2007/000122.html, https://www.engadget.com/2011-03-24-apple-to-drop-samba-networking-tools-from-lion.html
    • Apple’a yakışır şekilde, SMB performansı birkaç yıl önce korkunç derecede yavaştı; yakın zamanda da ancak idare eder seviyeye geldi, aynı donanımdaki NFS’den ve ironik şekilde Appleshare’den hâlâ çok daha yavaş.
      Birkaç yıl önce 10GbE ile büyük bir NAS’a bağlı bir Hackintosh’ta BlackMagic Disk Speed Test ile ölçtüğümde Windows’un SMB’si 900MB/s, macOS’in SMB’si 200MB/s, macOS’in NFS ve AFP’si ise ikisi de 1000MB/s verdi.
      Profesyonel işle ilgili macOS özellikleri ne yazık ki gülünç düzeyde.
      AFP’nin öldüğü söyleniyor ama benim Mac Pro’mda istemci olarak hâlâ gayet iyi çalışıyor; performansı SMB’den o kadar iyi ki neredeyse komik geliyor.
    • Bizzat başınıza gelirse eğlenceli değil ama aynı şey BTRFS ve ZFS üzerinde de mümkün.
      Sonuna kadar doldurursanız sorun çıkabilir.
      BTRFS, metadata alanı hâlâ varken salt okunur moda geçmeye çalışır; bu da güvenli modda yeniden bağlayıp bir şeyleri silebilmenizi sağlar, ancak kusursuz bir koruma mekanizması yoktur.
      Bildiğim kadarıyla NTFS ve FAT32 journaling dosya sistemleri değil.
    • Şimdiye kadar bu, düzgün bir teknik açıklama gibi görünen tek yorum.

  • İlk işimde başıma böyle bir şey gelmişti
    Yanlışlıkla kümeyi job dosyalarıyla doldurmuştum; sistem yöneticisi hızlıca düzeltmem için e-posta göndermeye başladı ama rm çalışmıyordu
    O zaman, silme işe yaramasa bile dosyayı kırpmanın genelde çalıştığını öğrendim; bu yüzden rm foo çalışmadığında çoğu zaman cat /dev/null > foo kullanmak yeterli olur

    • Kabukta :>filepath çoğu zaman işe yarar
      Ancak bazı dosya sistemleri bunu da yapamayabilir
      Böyle durumlarda dosya sisteminin boyut büyütmeyi, boyut küçültmeyi, geçici ek depolama alanını desteklemesini ya da alttaki sistemin backing storage ekleyip kaldırabilmesini ummanız gerekir
      btrfs gibi, tek blok aygıtına yönelik yapıya geri dönmek için ayrı bir komut da gerekebilir
    • Birkaç yıl önce, dosya sistemine her zaman yazabilmesi gereken kritik bir altyapının deadlock’a girip kurtarılamaz şekilde bozulabileceği bir durum vardı
      Bu yüzden yedekleme sürecinin periyodik olarak çöp veriyi doğrudan /dev/null’a göndermesini sağladık; muhtemelen o kirli hack hâlâ çalışıyordur
      /dev/null büyülü bir şey; hakkında okumaya değer
    • Aslında sadece >file da yeter
    • Ancak buradaki birçok yorumda olduğu gibi kırpmanın bile başarısız olduğu durumlar da var
      21. yüzyıl dosya sistemi biçimleri UFS’den çok daha karmaşık; snapshot ve journaling gibi özellikler, dosya sisteminin kendi kendini deadlock’a sokmasının yeni yollarını ortaya çıkarıyor
    • Samba log seviyesini debug için fazla yüksek ayarlayıp geri almayı unuttuğum için, devasa bir log dosyasıyla ZFS kök SSD’sini doldurmuştum
      Sonunda truncate ile toparlamak zorunda kaldım
      ZFS’nin bu durumlarda daha iyi olduğunu biliyordum ama yine de gerçekten batırdığınızı hissettiğiniz o “ah… kahretsin” batma hissi aynıydı

  • Time Machine sürekli kötüleşiyor gibi görünüyor
    Neden onu kararlı ve düzgün çalışır hale getirmek için bir motivasyon yok, anlamıyorum
    sparse bundle’ın bozulup yeni bir yedek başlatmak zorunda kalmam ya da özelliğin başarısız olması gibi şeyler yaşadıkça, artık Time Machine kurmaya pek değmediğini düşünüyorum
    Her seferinde düzgün çalışan iOS/iPadOS yedekleriyle tamamen zıt

    • Çünkü artık Time Capsule satmıyorlar
      Apple, insanların her şeyi iCloud’a yedekleyip servis gelirlerini artırmasını istiyor
    • Mac kullanmayan biri olarak bakınca, bu; penguen maskotu olan ya da merkezi Washington’da bulunan bir masaüstü işletim sistemi olsaydı büyük tepki çekecek felaket ve savunulamaz bir bug gibi geliyor
    • Time Machine’in birden artık çalışmak istemediğine karar verip yedeği silmem ve baştan başlamam gereken durumların sayısı çok fazla
    • macOS kalite kontrolü Scott Forstall kovulduğundan beri düşüşte; aslında onun döneminde de şaşırtıcı derecede iyi değildi
    • Benim deneyimim farklı
      Birkaç Mac’te yıllardır Samba paylaşımı üzerinde Time Machine çalıştırıyorum ve aksine yalnızca iyileşme gördüm
      Eskiden Time Machine sparse bundle’ı sık sık bozulur, yeniden oluşturmam ya da önceki ZFS snapshot’ını geri yükleyip devam etmem gerekirdi
      O zamanlar bunun SMB değil AFP olduğunu sanıyorum
      Son zamanlarda hiçbir cihazda böyle bir sorun yaşamadım; Time Machine yedekleri için önerilen belirli bayrakları smb.conf içinde açık tutuyorum

  • Buna karşılık ZFS’te, büyük bir işlem sırasında alanın bitip dosya sisteminin durmasını önlemek için slop space bulunur
    Varsayılan olarak volume alanının %3,2’sini, en fazla 128GB’a kadar ayırır
    Bu nedenle Linux kernel ayarı olan spa_slop_shift değerini değiştirip slop space’i azaltırsanız, dosya silme işlemini başarıyla tamamlamak için kullanılabilecek en fazla 128GB ek alanı geri kazanabilirsiniz: https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Module%20Parameters.html#spa-slop-shift

    • Doğru
      Bu nedenle disk alanının belirli bir yüzdesini ayırma özelliği, ZFS ya da Linux var olmadan onlarca yıl önce de “gerçek” dosya sistemlerinin yaygın bir özelliğiydi
      Bu, 1980’lerdeki çoğu MS-DOS shareware terminal programının sınırlı bant genişlikli bağlantılarda dosya indirmeyi çok iyi yapmasına, günümüz MS Windows’unun ise önemsiz olması gereken bu tür bir işi bile berbat yapmasına benziyor
    • ext4’te de aynı özellik var; sadece adı reserved blocks
      Ayrıntılar için man tune2fs’e bakabilirsiniz
      Modern ya da pek de modern olmayan diğer dosya sistemlerinin çoğunda da aynısı var
      Hatırladığım kadarıyla 1980’lerde SunOS’un UFS’inde de vardı: https://en.wikipedia.org/wiki/SunOS

  • İnsanlar bir şeyi silmenin gerçekten geçici ya da kalıcı olarak daha fazla alan gerektirebileceği fikrini anlamakta zorlanıyor
    Diğer yorumlar snapshot, journaling gibi modern dosya sistemlerinin silme işlemi için neden boş alandan tahsis yapması gerektiğini ayrıntılı ele almış
    Başka alanlarda da benzer şekilde, Wikipedia’nın ilk 10 yılında sayfaları silerek sunucu alanı tasarrufu yapma girişimlerinin aslında ters etki yarattığını sık sık açıklamak gerekirdi
    Çünkü en azından 2004 civarından sonra silme işlemi dahili veritabanına bir kayıt ekliyordu
    Rahul Dhesi’nin ZOO arşiv biçiminde öğe silmek yalnızca header kaydında bir bayrak ayarlamaktan ibaretti; ayrıca yeni sürüm eklerken eski sürümün üzerine yazmayan VMS tarzı dosya sürümleme de vardı
    MS/DR/PC-DOS ve FAT döneminde, silme geri alma yardımcı programı kuruluysa bir dosyayı silerken kurtarma bilgilerini içeren veritabanına yeni bir öğe kaydetmek gerektiğinden daha fazla alan gerekebiliyordu
    Bazı eski disk sıkıştırma yardımcı programları metadata’yı bile sıkıştırdığı için, metadata değişikliğinin sıkıştırma oranını değiştirip dışarıdan görünen volume boyutunu gerçekten artırdığı nadir durumlar da mümkündü
    Silerek alan açma düşüncesi yaygın olsa da, teknik olarak her zaman doğru değildir

  • Ekim 2018’de aynı sorunu yaşadım ve aşağıdaki Stack Overflow sorusuna not düşmüştüm
    Neyse ki kaldırabileceğim ek bir APFS bölümü vardı, böylece disk alanı açabildim
    Bunu fark edene kadar epey zaman geçti ve o sırada gerçekten panik halindeydim
    https://apple.stackexchange.com/questions/338721/disk-full-terminal-in-recovery-mode-won-t-delete-files-boot-kernel-panics
    macOS Mojave’yi yeni güncelledikten sonra bir .dmg oluştururken diski doldurdum ve sistem kilitlendi
    Yeniden başlatınca kernel panic oldu; kurtarma modunda açıp diski bağladıktan sonra terminalde rm /path/to/large/file çalıştırdım ama No space left on device hatası çıktı
    2008’deki Unix başlığıyla özünde aynı sorundu: https://www.unix.com/linux/69889-unable-remove-file-using-rm-disk-space-full.html
    echo x > /path/to/large/file da işe yaramadı; “sürücüyü silip yedekten geri yükle” dışında bir öneriye ihtiyacım vardı

    • Yaklaşık 1 GB’lık küçük bir ek bölüm oluşturup bırakmak iyi bir sigorta olabilir
      Eski Unix dosya sistemlerinin root için %5 ayırmasına benzer
    • O StackExchange yazısına sonradan başka olası çözümler de eklenmiş
      Sanal bellek bölümünü silmek, yeterince büyükse dosya silmeye yetecek kadar alanı geri verebilir
    • APFS’de bu o kadar basit değil
      Çünkü konteynerler ancak gerçekten kullanıldıklarında tahsis ediliyor

  • Etkileyici
    rm’nin bile başarısız olduğu bir durumu hiç yaşamadım ama dahili depolaması 256 GB veya daha az olan modern Mac’leri kullanıp yönetmenin tatsızlığını yaşadım
    Bu yüzden yaklaşık 16 GB’lık bir yer tutucu dosya oluşturmayı tercih ediyorum
    Zaten alan dolup güncellemeleri veya başka işleri engellerse, ncdu ile cerrahi operasyon yapar gibi temizlik yapmak yerine sadece o dosyayı silmek yeterli oluyor

  • iPhone’da da benzer bir şey yaşadım
    Disk o kadar doluydu ki bir şeyleri silsem de gerçekte hiçbir şey olmuyormuş gibi görünüyordu
    Yeniden başlatınca giriş yapamadım; tekrar yeniden başlatınca boot loop’a düştü
    Bir kez daha yeniden başlatınca ana ekranda uygulama simgeleri duruyor ama gerçek uygulamalar kaybolmuş, simgeler boş ve açılmıyor halde tutarsız bir durumla açıldı
    Veri bütünlüğünden endişe ettiğim için sonunda yedekten geri yükledim
    Bunun APFS’nin yazarken kopyalama yöntemi kullanması ve anlık görüntüleri desteklemesinden kaynaklandığına eminim
    Değişiklikler hemen kalıcı olarak uygulanmıyor ve dosyanın önceki sürümü anlık görüntüde kalıyorsa, anlık görüntü metaverisi için bile yer kalmadığında işler zorlaşıyor
    Disk alanı azaldığında anlık görüntüler atlanabilir belki ama yine de CoW metaverisi sorunu kalıyor

    • Ben de tam olarak aynı şeyi yaşadım
      2024’te bile tüm o akıllı APFS birim yönetimi özellikleri varken, sadece kullanıcı depolamasını doldurarak iPhone gibi “mühürlü” bir cihazı DFU kurtarma gerektiren hale getirebilmek şaşırtıcı
      Buna karşılık tek veri/önyükleme birimi kullanan Windows 11 iş dizüstü bilgisayarında yanlışlıkla alanı tamamen doldurduğumda hâlâ önyükleyip sorunu temizleyebildim

  • Kısa süre önce bir Linux kurulumunun sistem bölümünde de benzer bir durum yaşadım
    Bölüm zaten en baştan çok küçüktü ve güncellemeler biriktikçe bir şeyleri silmeye başlayacak kadar bile neredeyse hiç alan kalmamıştı
    Azıcık bile silebileceğim bir alt dizin bulmam yaklaşık 30 dakikamı aldı
    İçe doğru açılan kapısını açamayacak kadar ıvır zıvırla dolu bir odada mahsur kalmış gibiydi
    O küçük başlangıç noktasından giderek daha büyük alanları silebilir hale geldim ve sonunda temizlikten sonra bunun bir daha olmaması için bölüm boyutunu büyüttüm

    • Baştan bölümü neden genişletmediğini merak ediyorum
      Deneyimli kullanıcılar için, bölümün arkasında her zaman biraz boş alan bırakmak çıkarılacak ders olmalı gibi görünüyor