Hyperspace: app para Mac que ahorra espacio en disco sin borrar archivos
(hypercritical.co)- Organizar archivos duplicados en Mac normalmente implica borrarlos, pero Hyperspace usa clones de APFS para hacer que archivos con el mismo contenido compartan datos y así recuperar espacio sin eliminar archivos
- Los clones copy-on-write de APFS, como “Duplicate” en Finder, comparten el original sin volver a escribir los datos reales, por lo que incluso duplicados grandes se completan casi al instante
- Cuando su disco empezó a llenarse, el desarrollador creó un script en Perl para encontrar archivos con el mismo contenido que no fueran clones, y descubrió que podía ahorrar decenas de GB, lo que luego evolucionó a una app
- La app se puede descargar gratis, escanear y verificar cuánto espacio podría ahorrarse, pero para recuperar espacio de verdad se requiere un pago
- Modifica archivos que no creó ni posee, así que el riesgo es alto, pero aun así podría dar una ayuda real a muchos usuarios de Mac
Recuperar espacio manteniendo los archivos con clones de APFS
- Hyperspace convierte en clones de APFS los archivos con el mismo contenido que no están en relación de clon, para que compartan una sola copia de los datos en disco
- Las apps tradicionales de archivos duplicados para Mac suelen encontrar duplicados y borrarlos para ahorrar espacio, pero Hyperspace recupera espacio sin eliminar archivos
- Entre las funciones clave de APFS están las instantáneas de puntos en el tiempo y los clones copy-on-write
- Las instantáneas se usan para hacer que los respaldos de Time Machine sean más estables y eficientes
- Los clones copy-on-write se basan en una estructura flexible entre las entradas de directorio y el contenido del archivo
- Si duplicas un archivo con el comando “Duplicate” en Finder, el contenido real del archivo no se copia; en su lugar se crea un archivo clon que comparte los datos con el original
- Gracias a esta estructura, la duplicación en Finder se completa casi al instante sin importar el tamaño del archivo
Lanzamiento y notas de desarrollo
- A finales de 2024, cuando el disco de su Mac empezó a llenarse, el desarrollador escribió un script en Perl para encontrar archivos no clonados con el mismo contenido y convertirlos en clones
- Ese script invoca una herramienta de línea de comandos escrita en C y otra herramienta de línea de comandos escrita en Swift
- Al ejecutarlo, mostró que se podían ahorrar decenas de GB de espacio, y después evolucionó a una app para Mac
- Hyperspace está disponible en la Mac App Store
- La descarga y el escaneo son gratuitos
- Para recuperar espacio real se necesita una compra dentro de la app
- Puedes ver más detalles en la documentación de Hyperspace
- En el plano del desarrollo, Hyperspace es la segunda app para Mac hecha con SwiftUI por el desarrollador, y la primera en usar el ciclo de vida de SwiftUI
- También es su segunda app en usar Swift 6
- Usar Swift 6 desde el inicio fue mucho más fácil que migrar una app ya publicada a Swift 6
- A Swift 6 todavía le faltan pulirse varias partes, y espera mejoras a futuro
- Hyperspace modifica archivos que la app no creó ni posee, igual que en el proceso de conversión de HFS+ a APFS
- El desarrollador la llama la app más riesgosa que ha hecho
- Al mismo tiempo, cree que podría ser la app más útil para más personas
1 comentarios
Opiniones de Hacker News
Hace tiempo hice una utilidad de línea de comandos
dedupque hace lo mismoTiene modo dry-run, elige “inteligentemente” el origen óptimo para los clones, entiende hard links y otros clones, preserva metadatos y también maneja correctamente archivos comprimidos con HFS
Todavía no ha corrompido mis datos, pero, como siempre con las herramientas de sistema de archivos, úsala bajo tu propio riesgo
0 - https://github.com/ttkb-oss/dedup
Hyperspace, por defecto, no escanea todos los archivos, sino solo los que están en una lista permitida, y parece tener una estructura en la que necesita entender el contenido de los archivos. Como usuario final no sé cómo distingue entre archivos Text y archivos Source Code; el escaneo predeterminado encontró solo 360 MB como candidatos a deduplicación, pero al permitir todos los archivos subió a 842 MB
Por defecto tampoco escanea archivos de menos de 100 KB; al desactivar el límite de tamaño y permitir todos los archivos, subió a 1.1 GB. Con todos los archivos y sin límite de tamaño, Hyperspace escaneó 67,309 de 68,874 archivos, y
dedupescaneó 67,426Hyperspace dijo que 29,522 archivos podían deduplicarse, y
dedupencontró 29,447. Hay una diferencia de uno porque 76 archivos ya estaban deduplicados, pero no sé la causa exactaEl tiempo de escaneo fue de unos 50 segundos para Hyperspace y 14 segundos para
dedup. Hyperspace parece escanear el sistema de archivos, luego calcular duplicados y después hacer la deduplicación; no sé por qué no combina los dos primeros pasos. Yo hice que, durante el escaneo, los metadatos del sistema de archivos se pongan en una cola y que el cálculo de duplicados arranque en paralelo; la mayoría de las discrepancias se pueden descartar solo con la información de tamaño que se obtiene “gratis” al recorrer directorios confts_readHyperspace dijo que podía ahorrar 1.1 GB, y
dedupencontró 1.04 GB más 882 MB ya ahorrados. No pienso comprar Hyperspace, así que no sé el tiempo real de deduplicación ni cómo preserva metadatos o maneja archivos raros, perodeduptardó 31 segundos sumando escaneo y deduplicaciónIncluso después de deduplicar con
dedup, Hyperscan todavía considera que hay 2 archivos que se pueden deduplicar. Hyperspace también parece manejar archivos con varios hard links, archivos vacíos y varias excepciones quededupcomprueba. Sin pagar no puedo probar si preserva ACL u otros atributos, pero al mirarstringsparece que los maneja; la compresión HFS es un caso límite complicado, así que aún no he confirmado cómo la trata el escaneo de HyperspaceEl proyecto no tiene licencia, así que, si es posible, estaría bueno que le pongas la licencia que prefieras. También hice un pull request para intentar mejorar un poco los pasos de instalación: https://github.com/ttkb-oss/dedup/pull/6
Incluso mirando solo ciertos subdirectorios, no era raro reemplazar 50 copias de algún archivo JS por una sola. Dicho eso, como es “pre-release” y tiene relativamente pocas estrellas en GitHub, me interesa saber qué tan estable es, porque una herramienta así da bastante miedo si tiene bugs
maketermine casi de inmediatoAntes usé https://github.com/sahib/rmlint y no tuve ninguna queja en particular
Al leer la parte de que “Hyperspace no tiene forma de cooperar con todas las demás apps ni con macOS mismo para coordinar un momento seguro para reemplazar archivos, ni forma de tomar por la fuerza el control exclusivo de esos archivos”, me quedé pensando por qué el sistema de archivos en sí no ejecuta en segundo plano un proceso de deduplicación parecido
Con ese nivel de abstracción parecería posible manejar esos problemas de seguridad, así que me pregunto qué desventajas tendría que ocurriera automáticamente dentro de APFS
Si se implementara a nivel de archivos, quizá usaría menos recursos, pero no sé si la implementación sería más simple o más compleja. Además, puede ser poco intuitivo que si cambias apenas 1 byte en un archivo grande, el sistema de archivos tenga que volver a copiar ese archivo, generando mucha actividad de disco
Hacer la deduplicación en esta capa es bueno porque permite deduplicar entre varios sistemas de archivos. Por ejemplo, si tienes mil sistemas con los mismos archivos del sistema operativo, puedes ahorrar muchísimo espacio, y muchas veces las diferencias se reducen a configuraciones específicas de cada sistema, como la clave del host o el nombre de host. Un sistema de archivos individual no puede detectar esa coincidencia
Sin embargo, se vuelve un problema si la deduplicación reduce el número de copias de un archivo con mucho uso. En el ejemplo anterior, si arrancas mil máquinas al mismo tiempo, puede generarse una carga de I/O enorme sobre la imagen del kernel
Le pides amablemente al sistema operativo que deduplique un conjunto de rangos especificado, y el SO bloquea los rangos, verifica que realmente sean idénticos y recién entonces hace la deduplicación. Como también recibes en un campo cuántos bytes se deduplicaron en cada rango, no hay forma de que un programa en espacio de usuario arruine los archivos
La usé bastante en ReFS con VM de Hyper-V, y el efecto fue impresionante. En ese momento eran principalmente VM mezcladas de Windows Server 2016/2019, y redujo el uso de almacenamiento en alrededor de 45%
Me gusta el modelo de escanear gratis para ver si hay beneficio, y pagar solo por el resultado real
Yo también tiendo a acumular archivos, así que lo probé y me mostró que podía recuperar 7 GB, pero para mí eso no alcanzaba como para pagar. Aun así, es bueno que exista una herramienta así
Después de todo, ¿cuántos archivos duplicados exactamente iguales vas a crear por accidente en un mes?
También hay opciones de suscripción o compra permanente para quienes realmente lo usen con frecuencia, pero para mucha gente un pago único dentro de la app que permite usarlo por un período limitado es bastante razonable. Y siempre puedes volver a ejecutarlo gratis para ver si ya se acumuló lo suficiente como para volver a pagar
No genero cantidades enormes, pero al juntar parte o todo pueden aparecer duplicados grandes. Normalmente pasa en situaciones raras, como tener que reconciliar los resultados de una recuperación de disco duro con archivos ubicados en otro lugar, o alinear una carpeta de descargas desordenada con una ubicación de destino organizada
Por ejemplo, una vez una copia de seguridad de Time Machine expulsó una versión antigua de un archivo que yo ni siquiera sabía que estaba registrado y que creía perdido desde hacía mucho, pero arruinó los nombres de los directorios y también ofuscó en cierta medida el contenido. Hay miles de directorios con nombres numéricos, y dentro podría haber archivos que quiero conservar, pero es difícil saber si ya los tengo o dónde están, porque no hay ninguna estructura. Al revés, muchas veces solo contienen un único archivo de texto del mismo sistema de compilación, y esos obviamente se pueden descartar
¿La gente ya está tan acostumbrada a la trampa de las suscripciones que esto se siente como un modelo nuevo?
Ojalá fuera fácil hacerlo así en otros tipos de software, pero por lo general hay una curva de aprendizaje que se interpone antes de poder ver el valor
Un consejo: para esas pruebas se puede usar una tarjeta virtual que puedas bloquear, así si te olvidas de cancelar, el cobro no pasa. Pero me pregunto si alguien encontró el precio real de la licencia en el sitio web
Me da curiosidad qué algoritmo usa la app para determinar si dos archivos son idénticos
Hay muchos métodos interesantes, como hashes o comparación bit a bit, pero cada uno tiene sus desventajas. Cuando hay muchísimos archivos, ¿cuál será la mejor forma?
Para cada archivo candidato se necesita una “clave” que permita comprobar si es igual a otros archivos candidatos. Como puede haber millones de archivos, la clave debe ser pequeña y rápida de generar, pero al mismo tiempo no debe tener falsos positivos
La respuesta obvia hoy es un hash SHA256 del contenido del archivo. Es muy rápido, no es demasiado grande con sus 32 bytes, y la probabilidad de falsos positivos o colisiones es tan baja que el mundo se acabaría antes de que te topes con una en la práctica. SHA256 es prácticamente el estándar de facto para este uso, así que me sorprendería bastante si hubiera hecho otra cosa
Era un sistema de archivos direccionado por contenido que usaba hashes para deduplicación, y como el hash se calcula al momento de escribir, el costo de rendimiento se distribuye
Así no hace falta aplicar hash al archivo grande completo, y solo se revisan más los archivos que tengan el mismo hash
Apple incluye una versión modificada del comando
cpque soporta la bandera-cpara poder usar la función de clones de APFScpque usas no lo soporta, también puedes llamarlo desde PythonPor ejemplo, algo como
import Foundation; Foundation.NSFileManager.defaultManager().copyItemAtPath_toPath_error_(...)Si el archivo A está en dos ubicaciones y, después de ejecutar esto, modifico
A_0, me pregunto siA_1también cambia o si solo se materializa el nuevo estado deA_0yA_1queda igual.Si modificas
A_0, en el momento de la escritura se crea una copia de ese archivo, yA_1no se toca.https://en.wikipedia.org/wiki/Copy-on-write#In_computer_stor...
Por eso deja
A_1tal como está y crea una nueva copia para los cambios deA_0. Para más detalles, consulta https://developer.apple.com/documentation/foundation/file_sy...Me llamó la atención la parte de que, antes de que Apple anunciara APFS en la WWDC 2017, como parte de una actualización de iOS 10.x convirtió en secreto todos los iPhone a APFS a modo de prueba y luego los revirtió a HFS+.
Me pregunto cómo se puede revertir un cambio de sistema de archivos cuando algo sale mal. Se puede validar bastante el código, pero si aparece algún problema, parece imposible dar marcha atrás.
En la migración de prueba de Apple, se ejecutaba la migración completa, incluida la creación del superbloque de APFS, pero se detenía justo antes del commit que reemplazaba de forma permanente el superbloque de HFS+ por el de APFS. Para revertir, bastaba con “simplemente” limpiar el superbloque y los bloques de metadatos de APFS que se habían creado.
Habiendo roto muchas cosas en entornos de producción, no sé si sería capaz de apretar el botón si me pidieran ejecutar una migración tan grande.
[0] https://www.youtube.com/watch?v=IcyaadNy9Jk&t=1670s
En el mundo open source también hay una herramienta que convierte sistemas de archivos ext a btrfs, y (1) se puede revertir y (2) mientras usas el sistema de archivos btrfs también puedes montar el sistema de archivos ext original.
Empieza con una historia, la reduce a un problema y luego muestra cómo la solución resuelve ese problema como por arte de magia.
Es un muy buen ejemplo de excelente marketing.
Lo probé en una carpeta enorme de proyecto NodeJS, pero dijo que solo podía ahorrar 1 GB en una carpeta de 8.1 GB.
Volví a ejecutarlo incluyendo la carpeta home del usuario, y con 731 K archivos, 127 K carpetas y 2,755 archivos objetivo, el ahorro total fue de apenas 1.3 GB. Es decir, solo unos 300 MB más que al ejecutarlo solo sobre la carpeta NodeJS.
También intenté escanear System y Library, pero fue rechazado por problemas de permisos. Como uso pnpm como gestor de paquetes, parece que el uso de disco ya está casi optimizado.
La idea es genial, pero con el precio actual cuesta justificarlo; sería bueno que funcionara como un proceso en segundo plano más o menos una vez al mes.
https://support.apple.com/guide/security/signed-system-volum...
Parece que la introdujeron para reducir el búfer de comparación, pero es posible que los archivos de node_modules queden por debajo de ese tamaño y no se hayan considerado.
Una vez hice un script parecido, pero más simple, que convertía archivos con el mismo contenido en hard links.
La motivación principal eran los paquetes de los entornos virtuales de Python. A menudo uno tiene instalados paquetes similares y, aunque las versiones sean distintas, muchos archivos siguen coincidiendo. Algunos paquetes como Numpy, PyTorch y TensorFlow son bastante enormes, así que se podía ahorrar bastante espacio en disco.
https://github.com/albertz/system-tools/blob/master/bin/merg...
[1] https://en.wikipedia.org/wiki/Apple_File_System#Clones
Supongo que otras herramientas como poetry, hatch y pdm también lo hacen, pero no las he usado tanto como para conocer los detalles de su comportamiento.