Hyperspace : l’app Mac qui économise de l’espace disque sans supprimer de fichiers

 (hypercritical.co)
1 points par GN⁺ 2025-02-26 | 1 commentaires | Partager sur WhatsApp
  • Sur Mac, le nettoyage des fichiers en double suppose généralement leur suppression, mais Hyperspace utilise des clones APFS pour faire partager les fichiers identiques et récupérer de l’espace sans les effacer
  • Les clones copy-on-write d’APFS, comme avec la commande « Duplicate » du Finder, partagent les données avec l’original au lieu de les réécrire, ce qui permet de dupliquer de très gros fichiers presque instantanément
  • Lorsque le disque du développeur a commencé à se remplir, il a créé un script Perl pour repérer les fichiers au contenu identique mais non clonés, et l’espace récupérable s’est révélé atteindre des dizaines de Go, ce qui a conduit à la création de l’app
  • L’app peut être téléchargée gratuitement pour lancer un scan et voir l’espace pouvant être économisé, mais la récupération réelle de cet espace nécessite un paiement
  • Comme elle modifie des fichiers qu’elle n’a ni créés ni possédés, elle comporte un risque élevé, mais pourrait malgré tout apporter une aide concrète à de nombreux utilisateurs de Mac

Récupérer de l’espace sans supprimer de fichiers grâce aux clones APFS

  • Hyperspace transforme en clones APFS les fichiers au contenu identique qui ne sont pas déjà en relation de clonage, afin qu’ils partagent une seule copie des données sur le disque
  • Les apps Mac classiques de recherche de doublons économisent généralement de l’espace en trouvant puis en supprimant les fichiers en double, alors que Hyperspace récupère de l’espace sans retirer les fichiers
  • Parmi les fonctions clés d’APFS figurent les instantanés ponctuels et les clones copy-on-write
    • Les instantanés servent à rendre les sauvegardes Time Machine plus fiables et plus efficaces
    • Les clones copy-on-write reposent sur une structure souple séparant les entrées de répertoire du contenu des fichiers
  • Quand on duplique un fichier avec la commande « Duplicate » dans le Finder, le contenu réel n’est pas recopié : un fichier clone est créé et partage les données avec l’original
    • Grâce à cette structure, la duplication dans le Finder se termine presque instantanément, quelle que soit la taille du fichier

Lancement et notes de développement

  • Fin 2024, alors que le disque de son Mac se remplissait, le développeur a écrit un script Perl pour trouver les fichiers non clonés ayant le même contenu et les convertir en clones
    • Ce script appelle un outil en ligne de commande écrit en C ainsi qu’un autre écrit en Swift
    • À l’exécution, l’espace économisable s’est élevé à des dizaines de Go, et le projet a ensuite évolué en app Mac
  • Hyperspace est proposé sur le Mac App Store
  • Du point de vue du développement, Hyperspace est la deuxième app Mac en SwiftUI du développeur, et sa première à utiliser le cycle de vie SwiftUI
    • C’est aussi sa deuxième app utilisant Swift 6
    • Utiliser Swift 6 dès le début du développement a été bien plus simple que de migrer une app déjà publiée vers Swift 6
    • Swift 6 comporte encore de nombreuses aspérités, et des améliorations sont attendues à l’avenir
  • Comme lors d’une conversion de HFS+ vers APFS, Hyperspace modifie des fichiers que l’app n’a ni créés ni possédés
    • Le développeur la décrit comme l’app la plus risquée qu’il ait jamais créée
    • Mais il estime aussi qu’elle pourrait être l’une des plus utiles au plus grand nombre

À lire aussi

1 commentaires

 
GN⁺ 2025-02-26
Avis sur Hacker News

  • J’avais créé il y a quelque temps un utilitaire en ligne de commande, dedup, qui fait la même chose
    Il a un mode dry-run, choisit « intelligemment » la meilleure source de clone, comprend les liens durs et les autres clones, préserve les métadonnées et gère correctement les fichiers compressés HFS
    Il n’a encore jamais corrompu mes données, mais comme toujours avec les outils de système de fichiers, vous l’utilisez à vos propres risques
    0 - https://github.com/ttkb-oss/dedup

    • Pour donner un aperçu après avoir seulement scanné, sans encore dédupliquer, l’écart est assez visible sur un espace de travail de 7,6 Go contenant des images disque, des binaires de programmes et des représentations intermédiaires
      Hyperspace ne scanne pas tous les fichiers par défaut : il ne regarde que ceux figurant sur une liste d’autorisation, et semble conçu pour devoir comprendre le contenu des fichiers. En tant qu’utilisateur final, je ne vois pas comment il distingue les fichiers texte des fichiers de code source ; le scan par défaut n’a trouvé que 360 Mo déduplicables, mais en autorisant tous les fichiers, ce chiffre est monté à 842 Mo
      Par défaut, il ne scanne pas non plus les fichiers de moins de 100 Ko ; en désactivant la limite de taille et en autorisant tous les fichiers, on monte à 1,1 Go. Avec tous les fichiers et sans limite de taille, Hyperspace a scanné 67 309 fichiers sur 68 874, tandis que dedup en a scanné 67 426
      Hyperspace a indiqué que 29 522 fichiers pouvaient être dédupliqués, et dedup en a trouvé 29 447. Il y a une différence d’un fichier puisque 76 fichiers étaient déjà dédupliqués, mais je n’en connais pas la cause exacte
      Le temps de scan était d’environ 50 secondes pour Hyperspace, contre 14 secondes pour dedup. Hyperspace semble scanner le système de fichiers, puis calculer les doublons, puis effectuer la déduplication ; je ne comprends pas pourquoi il ne regroupe pas les deux premières étapes. De mon côté, je mets les métadonnées du système de fichiers en file pendant le scan et je lance le calcul des doublons en parallèle ; la plupart des divergences peuvent être éliminées uniquement avec l’information de taille obtenue « gratuitement » lors du parcours des répertoires avec fts_read
      Hyperspace annonçait 1,1 Go économisables, tandis que dedup a trouvé 1,04 Go, plus 882 Mo déjà économisés. Je n’ai pas l’intention d’acheter Hyperspace, donc je ne sais pas ce qu’il en est du temps réel de déduplication, de la préservation des métadonnées ni de la gestion des fichiers atypiques, mais dedup a pris 31 secondes au total pour scanner et dédupliquer
      Après une déduplication avec dedup, Hyperscan estime encore qu’il reste 2 fichiers déduplicables. Hyperspace semble aussi gérer les fichiers avec plusieurs liens durs, les fichiers vides et plusieurs cas particuliers que dedup vérifie. Je ne peux pas tester la préservation des ACL ou d’autres attributs sans payer, mais d’après strings, cela semble pris en charge ; la compression HFS étant un cas limite délicat, je n’ai pas encore vérifié comment le scan d’Hyperspace la traite
    • Je l’ai lancé sur un répertoire de développement Postgres, où beaucoup de fichiers sont presque identiques, et j’ai économisé environ 1,7 Go
      Comme le projet n’a pas de licence, ce serait bien d’en ajouter une de votre choix si possible. J’ai aussi ouvert une pull request pour essayer d’améliorer un peu les étapes d’installation : https://github.com/ttkb-oss/dedup/pull/6
    • Je viens de l’essayer et ça fonctionne bien. C’est seulement en voyant combien de doublons il y avait réellement dans certains types de fichiers, en particulier dans node_modules, que j’ai pris conscience du potentiel de cette technique
      Même en ne regardant que certains sous-répertoires, il n’était pas rare de remplacer 50 copies d’un même fichier JS par une seule. Cela dit, comme c’est une « pre-release » et que le dépôt GitHub a encore assez peu d’étoiles, je m’interroge sur sa stabilité : avec ce genre d’outil, les bugs peuvent faire assez peur
    • La documentation est excellente, et le fait que make se termine presque instantanément est aussi impressionnant
    • Pour une liste d’alternatives, voir les commentaires de https://news.ycombinator.com/item?id=38113396
      J’ai utilisé https://github.com/sahib/rmlint par le passé et je n’avais pas vraiment de reproches à lui faire

  • En lisant le passage disant qu’« Hyperspace n’a aucun moyen de coopérer avec toutes les autres apps ni avec macOS lui-même pour coordonner le moment où le remplacement de fichiers est sûr, ni aucun moyen de prendre de force le contrôle exclusif de ces fichiers », je me demande pourquoi le système de fichiers lui-même ne lance pas en arrière-plan un processus de déduplication similaire
    À ce niveau d’abstraction, on pourrait penser que ce genre de problème de sûreté est gérable ; je me demande donc quels seraient les inconvénients si cela se faisait automatiquement à l’intérieur d’APFS

    • Avec ZFS, cela consomme beaucoup de RAM. Sans doute parce que ZFS travaille au niveau des blocs et doit donc suivre un grand nombre de blocs à comparer lorsqu’un nouveau bloc est écrit
      Une implémentation au niveau des fichiers pourrait réduire l’utilisation des ressources, mais je ne sais pas si elle serait plus simple ou plus complexe. Et le fait que, dans un gros fichier, modifier un seul octet obligerait le système de fichiers à recopier ce fichier, générant beaucoup d’activité disque, n’est pas forcément intuitif
    • Les périphériques de stockage par blocs font souvent ce genre de choses avec la compression. Bien sûr, cela échoue si le système de fichiers chiffre les blocs qu’il envoie au périphérique
      Faire la déduplication à cette couche est intéressant, car elle peut alors s’appliquer à plusieurs systèmes de fichiers. Par exemple, si l’on a mille systèmes contenant les mêmes fichiers d’OS, on peut économiser énormément d’espace, les différences se limitant souvent à des réglages propres à chaque système, comme la clé d’hôte ou le nom d’hôte. Un système de fichiers isolé ne peut pas repérer cette similarité
      En revanche, cela pose problème si la déduplication réduit le nombre de copies d’un fichier très sollicité. Dans l’exemple précédent, si les mille machines démarrent en même temps, l’image du noyau peut subir une énorme charge d’I/O
    • Sous Linux, c’est l’API de déduplication standard utilisée par btrfs et XFS
      On demande poliment au système d’exploitation de dédupliquer un ensemble de plages donné ; l’OS verrouille les plages, vérifie qu’elles sont réellement identiques, puis seulement effectue la déduplication. Comme un champ indique aussi combien d’octets ont été dédupliqués dans chaque plage, un programme en espace utilisateur n’a aucun moyen de corrompre les fichiers
    • ZFS fait effectivement ce genre de chose : https://www.truenas.com/docs/references/zfsdeduplication/
    • Windows Server propose aussi cette fonctionnalité sur les volumes NTFS et ReFS
      Je l’ai beaucoup utilisée avec ReFS pour des VM Hyper-V, et l’effet était impressionnant. À l’époque, il s’agissait surtout de VM mêlant Windows Server 2016/2019, et l’utilisation du stockage avait diminué d’environ 45 %

  • J’aime bien le modèle qui consiste à scanner gratuitement pour voir s’il y a un gain, puis à ne payer que pour le résultat réel
    Comme j’ai aussi tendance à accumuler les fichiers, je l’ai lancé et il m’a indiqué 7 Go récupérables, mais pour moi ce n’était pas assez pour justifier de payer. Cela dit, c’est bien que ce genre d’outil existe

    • Ils ont expliqué ce modèle dans un podcast. Beaucoup d’utilisateurs vont l’acheter, l’exécuter une fois, économiser quelques Go, puis s’arrêter là ; un abonnement n’a donc pas vraiment de sens
      Après tout, combien de doublons parfaitement identiques peut-on créer par erreur en un mois ?
      Il existe aussi un abonnement ou une option d’achat définitif pour ceux qui l’utiliseront souvent, mais pour beaucoup de gens, un achat intégré ponctuel donnant accès pendant une période limitée est assez raisonnable. Et on peut toujours le relancer gratuitement pour voir si assez de doublons se sont accumulés pour payer à nouveau
    • Pour moi, la valeur de ce type d’app de déduplication tient moins au gain d’espace qu’au fait de ne pas laisser traîner de fichiers en double
      Je n’en crée pas des quantités énormes, mais certains doublons, partiels ou complets, peuvent devenir gros une fois réunis. Cela arrive souvent dans des situations un peu étranges, quand il faut rapprocher le résultat d’une récupération de disque dur avec des fichiers situés ailleurs, ou aligner un dossier Téléchargements en désordre avec une destination bien organisée
      Par exemple, une sauvegarde Time Machine a un jour fait ressortir d’anciennes versions de fichiers dont je ne savais même pas avoir gardé la trace et que je pensais perdus depuis longtemps, mais elle avait abîmé les noms de répertoires et quelque peu obscurci le contenu. Il y avait des milliers de répertoires aux noms numériques, pouvant contenir des fichiers que je voulais conserver, sans structure permettant de savoir si je les avais déjà ni où ils se trouvaient. À l’inverse, beaucoup ne contenaient qu’un seul fichier texte de build system identique, que je pouvais évidemment jeter
    • Je dois être vieux, parce que je me souviens qu’il y a dix ans, la plupart des logiciels fonctionnaient comme ça
      Les gens sont-ils déjà tellement habitués aux pièges des abonnements que cela leur semble être un nouveau modèle ?
    • J’aime vraiment ce modèle tarifaire
      J’aimerais que ce soit aussi facile à appliquer à d’autres logiciels, mais en général, la courbe d’apprentissage bloque avant même qu’on en perçoive la valeur
    • C’est beaucoup plus rafraîchissant qu’un « essai gratuit » dont il faut penser à annuler l’abonnement
      Petite astuce : pour ce genre d’essai, utiliser une carte virtuelle que l’on peut verrouiller permet de bloquer le paiement si l’on oublie d’annuler. Mais je me demande si quelqu’un a trouvé le vrai prix de la licence sur le site web

  • Je me demande quel algorithme l’app utilise pour déterminer si deux fichiers sont identiques
    Il existe beaucoup de méthodes intéressantes, comme les hachages ou la comparaison bit à bit, mais chacune a ses inconvénients. Quelle est la meilleure approche quand il y a énormément de fichiers ?

    • Je ne sais pas exactement ce que fait Siracusa, mais on peut deviner
      Pour chaque fichier candidat, il faut une « clé » permettant de savoir s’il est identique à un autre candidat. Comme il peut y avoir des millions de fichiers, cette clé doit être petite et rapide à générer, tout en évitant les faux positifs
      Aujourd’hui, la réponse évidente est un hachage SHA256 du contenu du fichier. C’est très rapide, la taille de 32 octets n’est pas énorme, et la probabilité de faux positif ou de collision est si faible que le monde aura probablement pris fin avant qu’on y soit confronté. SHA256 est de fait le standard pour ce type d’usage ; je serais donc assez surpris qu’il ait choisi autre chose
    • Cela me fait penser à https://en.wikipedia.org/wiki/Venti_(software)
      C’était un système de fichiers à adressage par contenu utilisant des hachages pour la déduplication, et comme le hachage était calculé au moment de l’écriture, le coût en performance était réparti
    • Je hacherais les 1024 premiers octets de chaque fichier, puis je ne passerais à la suite qu’en cas de collision
      Ainsi, pas besoin de hacher entièrement les gros fichiers ; seuls les fichiers ayant le même hachage seraient examinés davantage

  • Apple fournit aussi une version modifiée de la commande cp prenant en charge le flag -c pour utiliser la fonction de clonage d’APFS

    • Si la version de cp utilisée ne le prend pas en charge, on peut aussi l’appeler depuis Python
      Par exemple avec quelque chose comme import Foundation; Foundation.NSFileManager.defaultManager().copyItemAtPath_toPath_error_(...)

  • Si le fichier A se trouve à deux emplacements et que, après avoir lancé ça, on modifie A_0, je me demande si A_1 change aussi, ou si seul le nouvel état de A_0 est matérialisé tandis que A_1 reste tel quel.

  • Un passage m’a frappé : avant qu’Apple n’annonce APFS à la WWDC 2017, dans le cadre d’une mise à jour iOS 10.x, ils auraient secrètement converti tous les iPhone vers APFS à titre de test, puis les auraient ramenés à HFS+.
    Je me demande comment on peut revenir en arrière quand un changement de système de fichiers se passe mal. On peut certes valider le code suffisamment, mais s’il y a un problème, ça semble impossible à retirer.

    • Si je me souviens bien, la migration de HFS+ vers APFS est possible sans toucher aux blocs de données, et les blocs de métadonnées APFS ainsi que le superbloc sont écrits en parallèle sur le disque.
      Lors de la migration de test d’Apple, ils ont effectué toute la migration, y compris la création du superbloc APFS, mais se sont arrêtés juste avant le commit qui remplaçait définitivement le superbloc HFS+ par le superbloc APFS. Pour revenir en arrière, il suffisait de « simplement » nettoyer le superbloc APFS et les blocs de métadonnées créés.
    • J’ai regardé la partie correspondante de la présentation [0], mais il y a très peu de détails, à part le fait que c’était fait comme test de cohérence.
      Ayant déjà cassé pas mal de choses en production, je ne sais pas si j’oserais appuyer sur le bouton si on me demandait de lancer une migration aussi énorme.
      [0] https://www.youtube.com/watch?v=IcyaadNy9Jk&t=1670s
    • Je pense que vous manquez d’imagination. Ce n’est pas une technologie « joyau de la couronne » que seul Apple pourrait maîtriser.
      Dans le monde open source aussi, il existe un outil qui convertit un système de fichiers ext en btrfs, et (1) c’est réversible et (2) on peut aussi monter le système de fichiers ext d’origine pendant qu’on utilise le système de fichiers btrfs.

  • Ça commence par une histoire, ça resserre ensuite sur le problème, puis ça montre la solution en train de résoudre ce problème comme par magie.
    C’est un très bon exemple de excellent marketing.

  • Je l’ai essayé sur un énorme dossier de projet NodeJS, mais il indiquait ne pouvoir économiser que 1 Go sur un dossier de 8,1 Go.
    Je l’ai relancé en incluant aussi le dossier personnel de l’utilisateur, et au total, sur 731 k fichiers, 127 k dossiers et 2 755 fichiers ciblés, l’économie n’était que de 1,3 Go. Soit seulement 300 Mo de plus que lorsque je l’avais lancé sur le seul dossier NodeJS.
    J’ai aussi essayé de scanner System et Library, mais ça a été refusé à cause de problèmes de permissions. Comme j’utilise pnpm comme gestionnaire de paquets, l’utilisation du disque est probablement déjà presque optimale.
    L’idée est sympa, mais au prix actuel, c’est difficile à justifier ; ce serait mieux sous forme de processus en arrière-plan lancé environ une fois par mois.

    • 1 Go sur 8,1 Go, ça veut dire que 12 % de l’espace utilisé était gaspillé, non ? Je me demande si j’ai bien lu.
    • pnpm vise à remplacer npm de façon transparente, et fait automatiquement de la déduplication.
    • macOS utilise des volumes scellés, ce qui explique les erreurs de permissions visibles dans System et Library.
      https://support.apple.com/guide/security/signed-system-volum...
    • Je n’ai pas eu le temps d’essayer moi-même, mais dans les captures de l’App Store, on voit clairement une option de taille minimale de fichier à prendre en compte.
      Elle semble avoir été introduite pour réduire le tampon de comparaison, mais il est possible que les fichiers de node_modules soient en dessous de cette taille et n’aient donc pas été pris en compte.
    • Je ne sais pas quel est le prix. Il ne semble être publié nulle part.

  • J’avais déjà créé un script similaire, mais plus simple, qui remplaçait les fichiers ayant le même contenu par des liens physiques.
    Ma motivation principale venait des paquets dans les environnements virtuels Python. On installe souvent des paquets similaires, et même lorsque les versions diffèrent, beaucoup de fichiers restent identiques. Certains paquets comme Numpy, PyTorch ou TensorFlow sont assez énormes, donc cela permettait d’économiser beaucoup d’espace disque.
    https://github.com/albertz/system-tools/blob/master/bin/merg...

    • Ici, il ne s’agit pas d’utiliser des liens physiques ou symboliques, mais la fonction de création de clones en copie à l’écriture du système de fichiers [1].
      [1] https://en.wikipedia.org/wiki/Apple_File_System#Clones
    • uv le fait par défaut.
      Je suppose que d’autres outils comme poetry, hatch ou pdm le font aussi, mais je les ai moins utilisés, donc je ne connais pas très bien les détails de leur fonctionnement.