Hyperspace: Dosya silmeden disk alanı kazandıran Mac uygulaması

 (hypercritical.co)
1 puan yazan GN⁺ 2025-02-26 | 1 yorum | WhatsApp'ta paylaş
  • Mac’te yinelenen dosya temizliği genellikle silmeyi varsayar; Hyperspace ise APFS klonları ile aynı içeriğe sahip dosyaların veriyi paylaşmasını sağlayarak dosyaları yerinde bırakırken alanı geri kazandırır
  • APFS’in copy-on-write klonları, Finder’daki “Duplicate” gibi gerçek veriyi yeniden yazmadan veriyi asıl dosyayla paylaşır; büyük dosya kopyaları bile neredeyse anında tamamlanır
  • Geliştirici, diski dolmaya başlayınca aynı içeriğe sahip olup klon olmayan dosyaları bulan bir Perl betiği yazdı; tasarruf edilebilecek alanın onlarca GB olduğu görülünce bu betik bir uygulamaya dönüştü
  • Uygulama ücretsiz indirilebilir, tarama yapıp tasarruf edilebilecek alanı gösterebilir; ancak gerçek alan geri kazanımı için ücretli ödeme gerekir
  • Kendi oluşturmadığı veya sahip olmadığı dosyaları değiştirdiği için risklidir; buna karşın birçok Mac kullanıcısına somut fayda sağlayabilir

APFS klonlarıyla dosyaları yerinde bırakarak alan geri kazanımı

  • Hyperspace, aynı içeriğe sahip dosyalar birbirleriyle klon ilişkisi içinde değilse, bunları APFS klonlarına dönüştürerek diskte verinin yalnızca tek bir kopyasının paylaşılmasını sağlar
  • Mevcut Mac yinelenen dosya uygulamaları genellikle yinelenen dosyaları bulup silerek alan kazandırır; Hyperspace ise dosyaları kaldırmadan alanı geri kazanır
  • APFS’in temel özellikleri arasında belirli an yedekleri (snapshot) ve copy-on-write klonları bulunur
    • Snapshot’lar, Time Machine yedeklerini daha güvenilir ve verimli hâle getirmek için kullanılır
    • Copy-on-write klonları, dizin girdileri ile dosya içeriği arasındaki esnek yapıya dayanır
  • Finder’da “Duplicate” komutuyla bir dosyayı çoğalttığınızda gerçek dosya içeriği kopyalanmaz; bunun yerine veriyi asıl dosyayla paylaşan bir klon dosya oluşturulur
    • Bu yapı sayesinde Finder’daki çoğaltma, dosya boyutundan bağımsız olarak neredeyse anında tamamlanır

Yayınlanma biçimi ve geliştirme notları

  • Geliştirici, 2024 sonlarında kendi Mac diski dolmaya başlayınca, aynı içeriğe sahip klon olmayan dosyaları bulup klona dönüştüren bir Perl betiği yazdı
    • Bu betik, C ile yazılmış bir komut satırı aracını ve Swift ile yazılmış bir komut satırı aracını çağırıyordu
    • Çalıştırma sonucunda tasarruf edilebilecek alanın onlarca GB olduğu görüldü ve daha sonra bir Mac uygulamasına dönüştü
  • Hyperspace Mac App Store’da sunuluyor
  • Geliştirme açısından Hyperspace, geliştiricinin ikinci SwiftUI Mac uygulaması ve SwiftUI life cycle kullandığı ilk uygulamadır
    • Aynı zamanda Swift 6 kullandığı ikinci uygulamadır
    • Geliştirme başlangıcından itibaren Swift 6 kullanmak, hâlihazırda yayımlanmış bir uygulamayı Swift 6’ya taşımaktan çok daha kolaydı
    • Swift 6’da hâlâ pek çok pürüzlü nokta var; gelecekte iyileştirmeler bekleniyor
  • Hyperspace, HFS+’tan APFS’e dönüştürme sürecine benzer şekilde, uygulamanın oluşturmadığı ve sahip olmadığı dosyaları değiştirir
    • Geliştirici bunu, yaptığı uygulamalar arasında en riskli uygulama olarak nitelendiriyor
    • Aynı zamanda en çok kişiye faydalı olabilecek uygulama olabileceğini düşünüyor

İlgili okumalar

1 yorum

 
GN⁺ 2025-02-26
Hacker News yorumları

  • Eskiden aynı işi yapan dedup adlı bir komut satırı aracı yazmıştım
    Dry-run modu var; “akıllıca” en iyi klon kaynağını seçiyor, hard link’leri ve diğer klonları anlıyor, metadata’yı koruyor ve HFS sıkıştırılmış dosyaları da düzgün işliyor
    Kendi verilerimi henüz hiç bozmadı ama dosya sistemi araçlarında her zaman olduğu gibi kullanım sorumluluğu size ait
    0 - https://github.com/ttkb-oss/dedup

    • Yalnızca tarama yapıp henüz tekilleştirme uygulamamış biri olarak yazarsam; disk image’ları, program binary’leri ve ara temsillerle çalışan 7,6 GB’lık bir çalışma alanında fark epey görünür
      Hyperspace varsayılan olarak tüm dosyaları taramıyor, yalnızca izin verilenler listesindeki dosyalara bakıyor ve dosya içeriğini anlaması gereken bir yapıda görünüyor. Son kullanıcı olarak Text dosyaları ile Source Code dosyaları arasındaki farkı nasıl ayırt ettiğini bilmiyorum; varsayılan tarama yalnızca 360 MB’ı tekilleştirme adayı olarak buldu, ama tüm dosyalara izin verince bu 842 MB’a çıktı
      Varsayılan olarak 100 KB altındaki dosyaları da taramıyor; boyut sınırını kapatıp tüm dosyalara izin verince 1,1 GB’a kadar çıktı. Tüm dosyalar ve boyut sınırı yok koşulunda Hyperspace 68.874 dosyanın 67.309’unu taradı, dedup ise 67.426 dosyayı taradı
      Hyperspace 29.522 dosyanın tekilleştirilebilir olduğunu söyledi, dedup ise 29.447 dosya buldu. Zaten tekilleştirilmiş 76 dosya olduğu için bir fark oluşuyor ama tam nedeni bilmiyorum
      Tarama süresi Hyperspace için yaklaşık 50 saniye, dedup için 14 saniyeydi. Hyperspace dosya sistemini taradıktan sonra tekrarları hesaplayıp ardından tekilleştirme yapıyor gibi görünüyor; ilk iki adımı neden birlikte yapmadığını bilmiyorum. Ben tarama sırasında dosya sistemi metadata’sını kuyruğa alıp paralel olarak tekrar hesaplamasını başlatacak şekilde yaptım; çoğu durumda uyuşmazlıkları elemek için fts_read ile dizinleri dolaşırken “bedavaya” elde edilen boyut bilgisi yeterli oluyor
      Hyperspace 1,1 GB tasarruf edilebileceğini söyledi; dedup ise 1,04 GB ve zaten tasarruf edilmiş 882 MB buldu. Hyperspace’i satın almayı düşünmediğim için gerçek tekilleştirme süresini, metadata korumasını veya tuhaf dosyaların işlenmesini bilmiyorum; ama dedup tarama ve tekilleştirmeyi birlikte 31 saniyede tamamladı
      dedup ile tekilleştirme yaptıktan sonra bile Hyperscan hâlâ tekilleştirilebilir 2 dosya olduğunu düşündü. Hyperspace de birden fazla hard link’i olan dosyaları, boş dosyaları ve dedupın kontrol ettiği çeşitli istisnaları işliyor gibi görünüyor. ACL veya diğer özelliklerin korunmasını ödeme yapmadan test edemiyorum ama strings çıktısına bakınca bunları işliyor gibi; HFS sıkıştırma ise zor bir sınır durumu olduğundan Hyperspace taramasının bunu nasıl ele aldığını henüz doğrulayamadım
    • Postgres geliştirme dizini gibi neredeyse aynı dosyaların çok olduğu bir yerde çalıştırınca yaklaşık 1,7 GB tasarruf etti
      Projede lisans yok; mümkünse tercih ettiğiniz lisansı eklemeniz iyi olur. Kurulum adımlarını biraz iyileştirmek için bir pull request de açtım: https://github.com/ttkb-oss/dedup/pull/6
    • Az önce denedim, iyi çalışıyor. Belirli dosya tiplerinde, özellikle node_modules içinde ne kadar çok tekrar olduğunu görünce bu tekniğin potansiyelini gerçekten anladım
      Yalnızca belirli alt dizinlere bakınca bile bir JS dosyasının 50 kopyasını tek bir dosyaya dönüştürmek nadir değildi. Ancak “pre-release” olduğu ve GitHub yıldızı da nispeten az olduğu için, böyle araçlarda hata olursa oldukça korkutucu olabileceğinden kararlılığını merak ediyorum
    • Dokümantasyonu harika; makein neredeyse anında bitmesi de etkileyiciydi
    • Alternatifler listesi için https://news.ycombinator.com/item?id=38113396 adresindeki yorumlara bakabilirsiniz
      Eskiden https://github.com/sahib/rmlint kullanmıştım, özel bir şikâyetim yoktu

  • “Hyperspace’in diğer tüm uygulamalarla veya macOS’in kendisiyle işbirliği yapıp dosya değişimi için güvenli anı koordine etmesinin bir yolu yok; ilgili dosyayı zorla tek başına denetlemesinin de bir yolu yok” kısmını görünce, dosya sisteminin kendisinin arka planda benzer bir tekilleştirme süreci neden çalıştırmadığını merak ettim
    Bu düzeyde bir soyutlama katmanı bu tür güvenlik sorunlarını yönetebilir gibi geliyor; APFS içinde otomatik olarak gerçekleşse ne gibi dezavantajları olurdu diye düşünüyorum

    • ZFS’te çok RAM kullanıyor. ZFS bunu blok düzeyinde yaptığı için, yeni bir blok yazıldığında karşılaştırılacak çok sayıda bloğu takip etmesi gerektiğinden gibi görünüyor
      Dosya düzeyinde uygulanırsa kaynak kullanımı azalabilir, ama uygulamanın daha basit mi daha karmaşık mı olacağından emin değilim. Ayrıca büyük bir dosyada yalnızca 1 bayt değişse bile dosya sisteminin o dosyayı yeniden kopyalaması gerekeceği için çok disk etkinliği oluşması sezgisel gelmeyebilir
    • Blok depolama aygıtlarında bu iş sıkça sıkıştırmayla birlikte yapılır. Elbette dosya sistemi aygıta gönderdiği blokları şifrelerse başarısız olur
      Bu katmanda tekilleştirme yapmak, birden çok dosya sistemi genelinde tekilleştirme yapabildiği için iyidir. Örneğin aynı işletim sistemi dosyalarına sahip bin sistem varsa depolama alanında muazzam tasarruf sağlanabilir; farklar çoğu zaman ana makine anahtarı veya ana makine adı gibi sisteme özgü ayarlardan ibaret olur. Tek bir dosya sistemi bu ortaklığı fark edemez
      Ancak tekilleştirme yüzünden yoğun kullanılan bir dosyanın kopya sayısı azalırsa sorun olur. Önceki örnekte bin makineyi aynı anda başlatırsanız kernel imajı üzerinde çok büyük I/O yükü oluşabilir
    • Linux’ta bu, btrfs ve XFS’in kullandığı standart tekilleştirme API’sidir
      Belirli aralık kümelerini işletim sisteminden kibarca tekilleştirmesini istersiniz; OS aralıkları kilitler, gerçekten aynı olduklarını doğrular ve ancak ondan sonra tekilleştirme yapar. Her aralıkta kaç baytın tekilleştirildiği de bir alan olarak geri döndüğünden, kullanıcı alanındaki programın dosyayı bozmasının bir yolu yoktur
    • ZFS gerçekten de bunu yapıyor: https://www.truenas.com/docs/references/zfsdeduplication/
    • Windows Server da bu özelliği NTFS ve ReFS birimlerinde sunuyor
      Hyper-V VM’leri barındıran ReFS üzerinde epey kullandım ve etkisi harikaydı. O dönemde VM’lerin çoğu Windows Server 2016/2019 karışımıydı; depolama kullanımını yaklaşık %45 azalttı

  • Taramayı ücretsiz yapıp bir kazanç olup olmadığını görmeyi, gerçek sonuçlar için ödeme yapma modelini seviyorum
    Ben de dosya biriktirmeye yatkınım, çalıştırdığımda 7 GB geri kazanılabilir dedi; ama benim için bu, para ödemeye değecek kadar değildi. Yine de böyle bir aracın olması güzel

    • Podcast’te bu modeli açıklamıştı. Birçok kullanıcı bunu satın alıp bir kez çalıştıracak, birkaç GB tasarruf edip işi bitireceği için abonelik pek mantıklı değil
      Zaten bir ay içinde yanlışlıkla tamamen aynı yinelenen dosyalardan ne kadar çok oluşturabilirsiniz ki?
      Gerçekten sık kullanacak kişiler için abonelik veya kalıcı satın alma seçenekleri de var, ama birçok kişi için sınırlı bir süre kullanılabilen tek seferlik uygulama içi satın alma oldukça makul. Üstelik istediğiniz zaman ücretsiz yeniden çalıştırıp, tekrar ödeme yapmaya değecek kadar birikmiş mi diye bakabilirsiniz
    • Bu tür tekilleştirme uygulamalarının değeri benim için alan tasarrufundan çok yinelenen dosyaların geride kalmamasına daha yakın
      Muazzam miktarlar oluşturmuyorum, ama bir kısmını veya tamamını birleştirince büyük yinelenen dosyalar ortaya çıkabiliyor. Genelde bir sabit disk kurtarma sonucunu başka konumlardaki dosyalarla eşleştirmek ya da dağınık bir İndirilenler klasörünü düzenli bir hedef konumla eşleştirmek gibi tuhaf durumlarda bu oluyor
      Örneğin Time Machine yedeği, kayıtlı olduğunu bile bilmediğim ve uzun zaman önce kaybettiğimi sandığım bir dosyanın eski sürümünü ortaya çıkarmıştı; ama dizin adlarını bozmuş ve içeriği de bir ölçüde okunmaz hâle getirmişti. Sayı adlarına sahip binlerce dizin var; içlerinde saklamak isteyeceğim dosyalar olabilir, ama zaten bende var mı, neredeler, hiçbir yapı olmadığı için anlamak zor. Öte yandan çoğu zaman yalnızca aynı build sistemi metin dosyasını içeren dizinler de oluyor; onları elbette atabilirsiniz
    • 10 yıl önce çoğu yazılımın böyle olduğunu hatırlıyor olmam beni o kadar yaşlı mı yapıyor acaba
      İnsanlar abonelik tuzaklarına şimdiden o kadar alıştı ki bu onlara yeni bir model gibi mi geliyor
    • Bu fiyatlandırma modelini gerçekten seviyorum
      Keşke başka yazılımlarda da bunu yapmak bu kadar kolay olsa; ama çoğu zaman değeri görmeden önce öğrenme eğrisi araya giriyor
    • İptal etmeyi hatırlamanız gereken “ücretsiz deneme”lerden çok daha ferahlatıcı
      Bir ipucu: Böyle denemelerde kilitlenebilir bir sanal kart kullanırsanız, iptal etmeyi unutsanız bile ödeme engellenir. Bu arada web sitesinde gerçek lisans fiyatını bulabilen oldu mu merak ediyorum

  • Uygulamanın iki dosyanın aynı olup olmadığını anlamak için hangi algoritmayı kullandığını merak ediyorum
    Hash, bit düzeyinde karşılaştırma gibi ilginç birçok yöntem var ama her birinin dezavantajları da var. Çok fazla dosya olduğunda en iyi yöntem nedir acaba

    • Siracusa’nın tam olarak ne yaptığını bilmiyorum, ama tahmin edilebilir
      Her aday dosya için, başka bir aday dosyayla aynı olup olmadığını kontrol edecek bir “anahtar” gerekir. Milyonlarca dosya olabileceğinden anahtar küçük ve hızlı üretilir olmalı; aynı zamanda yanlış pozitif olmamalı
      Bugün obvious yanıt, dosya içeriğinin SHA256 hash’i. Çok hızlı, 32 baytla boyutu da pek büyük değil; yanlış pozitif veya çakışma olasılığı da pratikte karşılaşmadan dünyanın sonu gelecek kadar düşük. SHA256 bu kullanım için fiilî standart; başka bir şey yaptıysa epey şaşırırım
    • https://en.wikipedia.org/wiki/Venti_(software) aklıma geliyor
      Hash’i tekilleştirme için kullanan içerik adreslemeli bir dosya sistemiydi; hash yazma anında hesaplandığı için performans maliyeti dağıtılıyordu
    • Tüm dosyaların ilk 1024 baytını hash’ler, yalnızca çakışma olursa bir sonraki aşamaya geçerdim
      Böylece büyük dosyanın tamamını hash’lemek gerekmez; yalnızca aynı hash’e sahip dosyalara ayrıca bakılır

  • Apple, APFS’in klonlama özelliğini kullanabilmek için -c bayrağını destekleyen değiştirilmiş bir cp komutu da sağlıyor

    • Kullandığınız cp bunu desteklemiyorsa Python ile de çağırabilirsiniz
      Örneğin import Foundation; Foundation.NSFileManager.defaultManager().copyItemAtPath_toPath_error_(...) gibi

  • A dosyası iki konumdaysa ve bunu çalıştırdıktan sonra A_0 üzerinde değişiklik yaparsam, A_1 de birlikte değişir mi, yoksa yalnızca A_0ın yeni durumu somutlaşıp A_1 olduğu gibi mi kalır merak ediyorum

  • WWDC 2017'de Apple'ın APFS'i duyurmasından önce, iOS 10.x güncellemesinin bir parçası olarak tüm iPhone'ları gizlice APFS'e deneme amaçlı dönüştürüp sonra HFS+'a geri döndürdüğü bölüm dikkatimi çekti
    Dosya sistemi değişikliği ters giderse nasıl geri alınabileceğini merak ediyorum. Kodu yeterince doğrulamak mümkün olabilir ama bir sorun çıkarsa geri çekmek imkânsız gibi görünüyor

    • Yanlış hatırlamıyorsam HFS+'tan APFS'e geçiş, veri bloklarına dokunmadan yapılabiliyor ve APFS metadata blokları ile superblock'ları diske paralel olarak yazılıyor
      Apple'ın test geçişinde, APFS superblock'unun oluşturulması dahil tüm migrasyon yapıldı; ancak HFS+ superblock'unun kalıcı olarak APFS superblock'u ile değiştirileceği commit'in hemen öncesinde duruldu. Geri almak için oluşturulan APFS superblock'u ve metadata bloklarını “sadece” temizlemek yeterliydi
    • Sunumun ilgili kısmını izledim [0]; tutarlılık testi olarak yapıldığı dışında neredeyse hiç ayrıntı yok
      Prod ortamda çok şey patlatmış biri olarak, böyle büyük bir migrasyonu çalıştırmam söylense düğmeye basabilir miydim bilmiyorum
      [0] https://www.youtube.com/watch?v=IcyaadNy9Jk&t=1670s
    • Bence hayal gücün biraz yetersiz. Bu, yalnızca Apple'ın yapabileceği taç mücevheri türünden bir teknoloji değil
      Açık kaynak dünyasında da ext dosya sistemini btrfs'e dönüştüren bir araç var; (1) geri alınabiliyor ve (2) btrfs dosya sistemini kullanırken özgün ext dosya sistemi de mount edilebiliyor

  • Bir hikâyeyle başlayıp sonra soruna daraltıyor, ardından çözümün o sorunu sihirli biçimde çözdüğünü gösteriyor
    İyi pazarlamanın çok iyi bir örneği

  • Devasa bir NodeJS proje klasöründe denedim ama 8,1 GB'lık klasörde yalnızca 1 GB tasarruf edilebileceğini söyledi
    Kullanıcı ana klasörünü de dahil ederek tekrar çalıştırdım; 731K dosya, 127K klasör ve 2.755 hedef dosya için toplam tasarruf sadece 1,3 GB oldu. Yalnızca NodeJS klasöründe çalıştırdığıma göre yaklaşık 300 MB daha fazla
    System ve Library'yi de taramaya çalıştım ama izin sorunları nedeniyle reddedildi. Paket yöneticisi olarak pnpm kullandığım için disk kullanımım zaten neredeyse optimuma yakın görünüyor
    Fikir güzel ama mevcut fiyatıyla haklı çıkarmak zor; ayda bir kez arka plan süreci olarak çalışan bir şey olsa iyi olurdu

    • 8,1 GB içinde 1 GB, kullanılan alanın %12'sinin boşa harcandığı anlamına gelmiyor mu? Doğru mu okudum diye düşündüm
    • pnpm, npm için drop-in bir alternatif olmayı hedefliyor ve otomatik olarak tekilleştirme yapıyor
    • macOS'te mühürlü volume olduğu için System ve Library'de izin hataları görülüyor
      https://support.apple.com/guide/security/signed-system-volum...
    • Kendim deneyecek vaktim olmadı ama App Store ekran görüntüsünde dikkate alınacak minimum dosya boyutu seçeneği açıkça görünüyor
      Karşılaştırma tamponunu küçültmek için eklenmiş gibi; node_modules içindeki dosyaların bu boyutun altında kalıp dikkate alınmamış olma ihtimali var
    • Fiyatının ne kadar olduğunu bilmiyorum. Hiçbir yerde yayımlanmamış gibi görünüyor

  • Aynı içeriğe sahip dosyaları hard linke çeviren benzer ama daha basit bir betik yazmıştım
    Asıl motivasyon Python sanal ortamlarındaki paketlerdi. Çoğu zaman benzer paketler kurulu oluyor ve sürümler farklı olsa bile birçok dosya hâlâ aynı kalıyor. Numpy, PyTorch, TensorFlow gibi bazı paketler epey büyük olduğundan disk alanından ciddi tasarruf sağlayabiliyordu
    https://github.com/albertz/system-tools/blob/master/bin/merg...

    • Bu, hard link veya sembolik link kullanmıyor; dosya sisteminin yazma sırasında kopyalama klonu oluşturma özelliğini kullanıyor [1]
      [1] https://en.wikipedia.org/wiki/Apple_File_System#Clones
    • uv bunu varsayılan olarak yapıyor
      poetry, hatch, pdm gibi diğer araçlar da muhtemelen yapıyordur ama ayrıntılı davranışlarını çok kullanmadığım için iyi bilmiyorum