Hyperspace: Aplikasi Mac yang Menghemat Ruang Disk tanpa Menghapus File

• Pembersihan file duplikat di Mac biasanya mengandalkan penghapusan, tetapi Hyperspace menggunakan klon APFS untuk membuat file dengan isi yang sama berbagi data sehingga ruang bisa dipulihkan tanpa menghapus file
• Klon copy-on-write di APFS, seperti fitur “Duplicate” di Finder, tidak menulis ulang data aktual dan malah membaginya dengan file asli, sehingga penyalinan berukuran besar pun selesai hampir seketika
• Saat disk mulai penuh, pengembang membuat skrip Perl untuk menemukan file dengan isi yang sama tetapi bukan klon, dan hasilnya menunjukkan ruang yang bisa dihemat mencapai puluhan GB, lalu berkembang menjadi aplikasi
• Aplikasi ini bisa diunduh gratis untuk memindai dan melihat potensi penghematan ruang, tetapi pemulihan ruang yang sebenarnya memerlukan pembayaran berbayar
• Karena aplikasi ini memodifikasi file yang tidak dibuat atau dimiliki sendiri, risikonya besar, tetapi justru karena itu juga bisa sangat membantu banyak pengguna Mac

---

Memulihkan ruang sambil tetap menyimpan file dengan klon APFS

• Hyperspace mengubah file-file dengan isi yang sama yang belum berada dalam hubungan klon menjadi klon APFS, sehingga hanya satu salinan data di disk yang dibagikan
• Aplikasi duplikat file di Mac yang sudah ada umumnya menghemat ruang dengan menemukan lalu menghapus file duplikat, tetapi Hyperspace memulihkan ruang tanpa menghapus file
• Fitur inti APFS mencakup snapshot titik waktu dan klon copy-on-write
  • Snapshot digunakan untuk membuat backup Time Machine lebih stabil dan efisien
  • Klon copy-on-write dibangun di atas struktur fleksibel antara entri direktori dan isi file
• Jika file digandakan dengan perintah “Duplicate” di Finder, isi file yang sebenarnya tidak disalin; yang dibuat adalah file klon yang berbagi data dengan file asli
  • Berkat struktur ini, proses duplikasi di Finder selesai hampir seketika terlepas dari ukuran file

Cara rilis dan catatan pengembangan

• Pada akhir 2024, ketika disk Mac milik pengembang mulai penuh, ia menulis skrip Perl untuk mencari file non-klon dengan isi yang sama lalu mengubahnya menjadi klon
  • Skrip ini memanggil alat baris perintah yang ditulis dalam C dan alat baris perintah yang ditulis dalam Swift
  • Hasil eksekusi menunjukkan potensi penghematan ruang sebesar puluhan GB, dan kemudian berkembang menjadi aplikasi Mac
• Hyperspace tersedia di Mac App Store
  • Unduhan dan pemindaian gratis
  • Pemulihan ruang yang sebenarnya memerlukan pembelian dalam aplikasi
  • Penjelasan lebih rinci tersedia di dokumentasi Hyperspace
• Dari sisi pengembangan, Hyperspace adalah aplikasi Mac SwiftUI kedua buatan pengembang, dan aplikasi pertama yang menggunakan SwiftUI life cycle
  • Ini juga merupakan aplikasi kedua yang menggunakan Swift 6
  • Menggunakan Swift 6 sejak awal pengembangan jauh lebih mudah dibanding mengonversi aplikasi yang sudah dirilis ke Swift 6
  • Swift 6 masih memiliki banyak bagian yang kasar, dan perbaikan di masa depan sangat diharapkan
• Hyperspace memodifikasi file yang tidak dibuat maupun dimiliki oleh aplikasi, mirip seperti proses konversi dari HFS+ ke APFS
  • Pengembang menyebutnya sebagai aplikasi paling berisiko yang pernah ia buat
  • Pada saat yang sama, ia menilai ini bisa menjadi aplikasi yang paling berguna bagi banyak orang

[GN⁺]

Opini Hacker News

• Dulu saya pernah membuat utilitas baris perintah dedup yang melakukan hal yang sama
  Ada mode dry run, memilih sumber clone terbaik secara “cerdas”, memahami hard link dan clone lain, mempertahankan metadata, dan juga menangani file terkompresi HFS dengan benar
  Data saya belum pernah dirusak olehnya, tetapi seperti biasa untuk alat sistem file, gunakan dengan risiko sendiri
  0 - https://github.com/ttkb-oss/dedup

  • Sebagai catatan setelah hanya memindai dan belum melakukan deduplikasi, terlihat perbedaan yang cukup besar pada ruang kerja 7,6GB yang berisi disk image, binary program, dan representasi perantara
    Secara default, Hyperspace tidak memindai semua file, melainkan hanya melihat file yang ada di allowlist, dan tampaknya strukturnya mengharuskan pemahaman terhadap isi file. Dari sudut pandang pengguna akhir, saya tidak tahu bagaimana ia membedakan file Text dan file Source Code; pemindaian default hanya menemukan 360MB sebagai target deduplikasi, tetapi ketika semua file diizinkan, angkanya naik menjadi 842MB
    Secara default, file di bawah 100KB juga tidak dipindai; ketika batas ukuran dimatikan dan semua file diizinkan, angkanya naik sampai 1,1GB. Dengan kondisi semua file dan tanpa batas ukuran, Hyperspace memindai 67.309 dari 68.874 file, sedangkan dedup memindai 67.426 file
    Hyperspace mengatakan 29.522 file bisa dideduplikasi, dan dedup menemukan 29.447 file. Ada selisih satu karena 76 file sudah dideduplikasi, tetapi saya tidak tahu penyebab pastinya
    Waktu pemindaian Hyperspace sekitar 50 detik, sedangkan dedup 14 detik. Hyperspace tampaknya memindai sistem file, lalu menghitung duplikasi, kemudian melakukan deduplikasi, tetapi saya tidak tahu mengapa dua tahap pertama tidak digabung. Saya membuatnya memasukkan metadata sistem file ke antrean saat pemindaian dan mulai menghitung duplikasi secara paralel; sebagian besar ketidakcocokan bisa disaring hanya dengan informasi ukuran yang didapat “gratis” saat menelusuri direktori dengan fts_read
    Hyperspace mengatakan bisa menghemat 1,1GB, sedangkan dedup menemukan 1,04GB serta 882MB yang sudah dihemat. Saya tidak berniat membeli Hyperspace, jadi saya tidak tahu waktu deduplikasi sebenarnya, apakah metadata dipertahankan, atau bagaimana ia menangani file aneh, tetapi dedup membutuhkan 31 detik untuk pemindaian dan deduplikasi digabung
    Setelah deduplikasi dengan dedup, Hyperscan masih menilai ada 2 file yang bisa dideduplikasi. Hyperspace juga tampaknya menangani file dengan banyak hard link, file kosong, dan berbagai pengecualian yang diperiksa dedup. Pelestarian ACL atau atribut lain tidak bisa diuji tanpa membayar, tetapi dari strings tampaknya ditangani; kompresi HFS adalah kasus tepi yang rumit, jadi saya belum bisa memastikan bagaimana pemindaian Hyperspace menanganinya
  • Saya mencobanya di tempat yang memiliki banyak file yang hampir sama, seperti direktori pengembangan Postgres, dan berhasil menghemat sekitar 1,7GB
    Proyeknya belum punya lisensi, jadi jika memungkinkan, akan bagus bila ditambahkan lisensi yang diinginkan. Saya juga membuat pull request untuk sedikit memperbaiki langkah instalasi: https://github.com/ttkb-oss/dedup/pull/6
  • Saya baru saja mencobanya dan bekerja dengan baik. Baru setelah melihat betapa banyak duplikasi pada tipe file tertentu, terutama di dalam node_modules, saya menyadari potensi teknik ini
    Bahkan hanya melihat subdirektori tertentu, tidak jarang ada 50 salinan suatu file JS yang bisa diganti menjadi satu. Namun karena ini “pre-release” dan jumlah bintang GitHub-nya juga masih sedikit, saya penasaran soal stabilitasnya, sebab alat seperti ini bisa cukup menakutkan jika ada bug
  • Dokumentasinya bagus, dan fakta bahwa make selesai hampir seketika juga mengesankan
  • Untuk daftar alternatif, lihat komentar di https://news.ycombinator.com/item?id=38113396
    Dulu saya pernah memakai https://github.com/sahib/rmlint dan tidak punya keluhan khusus

• Melihat bagian yang mengatakan “Hyperspace tidak punya cara untuk bekerja sama dengan semua app lain atau macOS sendiri guna mengoordinasikan kapan aman mengganti file, dan juga tidak punya cara untuk memaksa kontrol eksklusif atas file tersebut”, saya jadi penasaran kenapa sistem file itu sendiri tidak menjalankan proses deduplikasi serupa di latar belakang
  Dengan lapisan abstraksi setingkat itu, rasanya masalah keamanan seperti ini bisa dikelola; saya bertanya-tanya apa kekurangannya jika hal ini terjadi otomatis di dalam APFS

  • Di ZFS, ini memakai banyak RAM. Sepertinya karena ZFS menanganinya di level blok, sehingga harus melacak banyak blok untuk dibandingkan saat blok baru ditulis
    Kalau diimplementasikan di level file, penggunaan sumber daya mungkin bisa berkurang, tetapi saya tidak tahu apakah implementasinya akan lebih sederhana atau lebih rumit. Selain itu, mungkin tidak intuitif bahwa mengubah hanya 1 byte pada file besar pun membuat sistem file harus mengkloning ulang file itu, sehingga menimbulkan banyak aktivitas disk
  • Pada perangkat penyimpanan blok, hal seperti ini sering dilakukan bersama kompresi. Tentu saja akan gagal jika sistem file mengenkripsi blok yang dikirim ke perangkat
    Deduplikasi di lapisan ini bagus karena bisa melakukan deduplikasi di banyak sistem file. Misalnya, jika ada seribu sistem dengan file sistem operasi yang sama, ruang penyimpanan bisa dihemat sangat besar, dan perbedaannya sering kali hanya konfigurasi per sistem seperti host key atau hostname. Satu sistem file saja tidak bisa mengenali kesamaan seperti ini
    Namun, deduplikasi bisa menjadi masalah jika jumlah salinan file yang sering digunakan berkurang. Dalam contoh tadi, jika seribu mesin di-boot bersamaan, image kernel bisa terkena beban I/O yang sangat besar
  • Di Linux, ini adalah API deduplikasi standar yang dipakai btrfs dan XFS
    Jika kita dengan sopan meminta sistem operasi untuk menduplikasi sekumpulan rentang tertentu, OS akan mengunci rentang itu, memverifikasi bahwa isinya benar-benar identik, baru kemudian melakukan deduplikasi. Karena jumlah byte yang berhasil dideduplikasi di tiap rentang juga dikembalikan lewat field, program user space tidak punya cara untuk merusak file
  • ZFS memang benar-benar melakukan hal seperti ini: https://www.truenas.com/docs/references/zfsdeduplication/
  • Windows Server juga menyediakan fitur ini pada volume NTFS dan ReFS
    Saya cukup banyak memakainya di ReFS yang menjalankan VM Hyper-V, dan hasilnya luar biasa. Saat itu VM-nya kebanyakan campuran Windows Server 2016/2019, dan penggunaan storage berkurang sekitar 45%

• Saya suka modelnya: pemindaian gratis untuk melihat apakah ada manfaat, lalu bayar hanya untuk hasil nyata
  Saya juga tipe yang suka menimbun file, jadi saya coba menjalankannya dan hasilnya menunjukkan 7GB bisa direklaim, tetapi bagi saya jumlah itu belum cukup untuk membayar. Tetap saja, bagus ada alat seperti ini

  • Mereka pernah menjelaskan model ini di podcast. Karena banyak pengguna akan membeli ini, menjalankannya sekali, menghemat beberapa GB, lalu selesai, langganan tidak terlalu masuk akal
    Lagi pula, seberapa sering dalam sebulan kita tidak sengaja membuat file duplikat yang benar-benar sama?
    Untuk orang yang benar-benar sering memakainya ada opsi langganan atau pembelian permanen, tetapi bagi banyak orang, pembelian dalam app sekali pakai untuk digunakan dalam periode terbatas cukup masuk akal. Dan kapan saja bisa dijalankan lagi secara gratis untuk melihat apakah sudah terkumpul cukup banyak sehingga layak membayar lagi
  • Nilai app deduplikasi seperti ini bagi saya lebih dekat ke tidak menyisakan file duplikat daripada menghemat ruang
    Saya tidak membuat jumlah yang sangat besar, tetapi jika sebagian atau semuanya digabung, bisa muncul file duplikat besar. Biasanya ini terjadi dalam situasi aneh seperti harus mencocokkan hasil pemulihan hard drive dengan file di lokasi lain, atau mencocokkan folder unduhan yang berantakan dengan lokasi tujuan yang sudah rapi
    Misalnya, pernah ada backup Time Machine yang memunculkan versi lama dari file yang bahkan tidak saya sadari masih punya catatannya dan saya kira sudah hilang lama, tetapi nama direktorinya rusak dan isinya juga agak diobfuskasi. Ada ribuan direktori bernama angka, dan di dalamnya mungkin ada file yang ingin saya simpan, tetapi tidak ada struktur sama sekali untuk mengetahui apakah saya sudah memilikinya atau di mana letaknya. Sebaliknya, sering juga isinya hanya satu file teks build system yang sama, dan yang seperti itu tentu bisa dibuang
  • Apakah saya sudah setua itu sampai masih ingat bahwa 10 tahun lalu kebanyakan software memang seperti ini?
    Apakah orang-orang sudah terlalu terbiasa dengan jebakan langganan sampai ini terasa seperti model baru?
  • Saya sangat suka model harga ini
    Andai saja hal ini mudah diterapkan di software lain, tetapi biasanya ada kurva belajar yang menghalangi sebelum kita bisa melihat nilainya
  • Ini jauh lebih segar daripada “uji coba gratis” yang mengharuskan kita ingat untuk membatalkannya
    Sebagai tip, untuk trial seperti itu gunakan kartu virtual yang bisa dikunci, sehingga jika lupa membatalkan, pembayaran akan ditolak. Tapi saya penasaran apakah ada yang berhasil menemukan harga lisensi sebenarnya di situs webnya

• Saya penasaran algoritma apa yang dipakai app ini untuk mengetahui apakah dua file identik
  Ada banyak cara menarik seperti hash, perbandingan tingkat bit, dan sebagainya, tetapi masing-masing punya kekurangan. Apa metode terbaik saat jumlah file sangat banyak?

  • Saya tidak tahu persis apa yang dilakukan Siracusa, tetapi bisa menebak
    Untuk tiap file kandidat, dibutuhkan “key” untuk memeriksa apakah sama dengan file kandidat lain. Karena filenya bisa jutaan, key harus kecil dan cepat dibuat, tetapi pada saat yang sama tidak boleh ada false positive
    Jawaban yang obvious sekarang adalah hash SHA256 dari isi file. Ini sangat cepat, ukurannya juga hanya 32 byte sehingga tidak terlalu besar, dan peluang false positive atau collision begitu kecil sampai dunia mungkin berakhir dulu sebelum kita benar-benar mengalaminya. SHA256 praktis merupakan standar de facto untuk penggunaan seperti ini, jadi saya akan cukup terkejut kalau mereka memakai hal lain
  • Saya jadi teringat https://en.wikipedia.org/wiki/Venti_(software)
    Itu adalah content-addressable file system yang memakai hash untuk deduplikasi, dan karena hash dihitung pada saat penulisan, biaya performanya tersebar
  • Saya akan meng-hash 1024 byte pertama dari semua file, lalu baru lanjut ke tahap berikutnya hanya jika ada collision
    Dengan begitu tidak perlu meng-hash seluruh file besar, dan hanya file yang punya hash sama yang diperiksa lebih lanjut

• Apple menyertakan perintah cp yang dimodifikasi dengan dukungan flag -c agar bisa memakai fitur clone APFS

  • Jika cp yang dipakai tidak mendukungnya, bisa juga memanggilnya lewat Python
    Misalnya seperti import Foundation; Foundation.NSFileManager.defaultManager().copyItemAtPath_toPath_error_(...)

• Jika file A ada di dua lokasi dan setelah menjalankan ini lalu A_0 dimodifikasi, saya penasaran apakah A_1 juga ikut berubah, atau hanya status baru A_0 yang diwujudkan sementara A_1 tetap seperti semula

  • Ada alasan mengapa ini disebut copy-on-write
    Saat A_0 dimodifikasi, salinan file itu dibuat pada saat penulisan, dan A_1 tidak disentuh
    https://en.wikipedia.org/wiki/Copy-on-write#In_computer_stor...
  • Ini memakai fitur copy-on-write dari sistem file
    Jadi A_1 dibiarkan apa adanya, dan salinan baru dibuat untuk perubahan pada A_0. Untuk detailnya, lihat https://developer.apple.com/documentation/foundation/file_sy...

• Bagian yang menarik perhatian adalah sebelum Apple mengumumkan APFS di WWDC 2017, sebagai bagian dari pembaruan iOS 10.x mereka diam-diam menguji konversi semua iPhone ke APFS lalu mengembalikannya ke HFS+
  Saya penasaran bagaimana mereka bisa melakukan rollback saat perubahan sistem file berjalan keliru. Kodenya memang bisa diverifikasi dengan cukup baik, tetapi jika ada masalah, tampaknya mustahil untuk dibatalkan

  • Kalau ingatan saya benar, migrasi dari HFS+ ke APFS bisa dilakukan tanpa menyentuh blok data, dan blok metadata APFS serta superblock ditulis ke disk secara paralel
    Dalam migrasi uji Apple, mereka menjalankan seluruh migrasi termasuk pembuatan superblock APFS, tetapi berhenti tepat sebelum commit yang mengganti superblock HFS+ secara permanen dengan superblock APFS. Untuk rollback, mereka cukup “membersihkan” superblock dan blok metadata APFS yang telah dibuat
  • Saya menonton bagian presentasi itu [0], tetapi hampir tidak ada detail selain bahwa itu dilakukan sebagai uji konsistensi
    Karena saya pernah memecahkan banyak hal di lingkungan produksi, kalau diminta menjalankan migrasi sebesar ini, saya tidak yakin bisa menekan tombolnya
    [0] https://www.youtube.com/watch?v=IcyaadNy9Jk&t=1670s
  • Sepertinya kurang berimajinasi. Ini bukan teknologi permata mahkota yang hanya bisa dilakukan Apple
    Di dunia open source juga ada alat untuk mengonversi sistem file ext ke btrfs, dan (1) bisa di-rollback serta (2) sistem file ext asli juga bisa di-mount saat memakai sistem file btrfs

• Dimulai dengan sebuah cerita, lalu dipersempit menjadi masalah, kemudian menunjukkan bagaimana solusinya menyelesaikan masalah itu seolah-olah dengan sihir
  Ini contoh yang sangat bagus dari pemasaran yang hebat

• Saya mencobanya pada folder proyek NodeJS yang besar, tetapi hasilnya mengatakan hanya bisa menghemat 1GB dari folder 8,1GB
  Saya menjalankannya lagi dengan menyertakan folder home pengguna, tetapi dari 731K file, 127K folder, dan 2.755 file target, total penghematan hanya 1,3GB. Itu hanya sekitar 300MB lebih banyak dibanding saat hanya menjalankannya pada folder NodeJS
  Saya juga mencoba memindai System dan Library, tetapi ditolak karena masalah izin. Karena saya memakai pnpm sebagai package manager, sepertinya penggunaan disk saya memang sudah hampir optimal
  Idenya keren, tetapi sulit dibenarkan dengan harga saat ini, dan akan bagus kalau bentuknya berupa proses latar belakang yang berjalan kira-kira sebulan sekali

  • Kalau 1GB dari 8,1GB, bukankah itu berarti 12% ruang yang dipakai terbuang? Saya jadi bertanya-tanya apakah saya membacanya dengan benar
  • pnpm bertujuan menjadi pengganti drop-in untuk npm, dan otomatis melakukan deduplikasi
  • macOS memiliki sealed volume, jadi itulah sebabnya muncul error izin di System dan Library
    https://support.apple.com/guide/security/signed-system-volum...
  • Saya tidak sempat mencobanya sendiri, tetapi di tangkapan layar App Store jelas terlihat ada opsi ukuran file minimum yang perlu dipertimbangkan
    Sepertinya itu diperkenalkan untuk mengurangi buffer perbandingan, dan mungkin file-file di node_modules berada di bawah ukuran ini sehingga tidak ikut dipertimbangkan
  • Saya tidak tahu berapa harganya. Sepertinya tidak dipublikasikan di mana pun

• Saya pernah membuat skrip yang mirip tetapi lebih sederhana, yang mengubah file dengan isi yang sama menjadi hard link
  Motivasi utamanya adalah paket di virtual environment Python. Sering kali ada paket-paket yang mirip terpasang, dan meskipun versinya berbeda, banyak file tetap identik. Beberapa paket seperti Numpy, PyTorch, dan TensorFlow cukup besar, sehingga bisa menghemat ruang disk cukup banyak
  https://github.com/albertz/system-tools/blob/master/bin/merg...

  • Ini bukan memakai hard link atau symbolic link, melainkan memakai fitur pembuatan clone copy-on-write dari sistem file [1]
    [1] https://en.wikipedia.org/wiki/Apple_File_System#Clones
  • uv menjadikan ini sebagai default
    Alat lain seperti poetry, hatch, dan pdm mungkin juga begitu, tetapi saya belum banyak memakainya jadi tidak tahu detail perilakunya