Je reviens dans ce fil pour rendre compte d'une expérimentation.
Dans un panneau du logiciel «
CronniX» dédié au
Cron pour l'utilisateur (et pas
pour le Système) --> j'ai défini une tâche
horaire consistant dans l'exécution de la commande :
- Pourquoi cette commande directe va-t-elle marcher > alors que tmutil doit être exécuté par l'utilisateur root (et pas par un admin macomaniac) pour tout ce qui est opératoire et pas informatif ? - parce que, pour éviter les complications liées à l'emploi de sudo - ce qui demande de renseigner un mot-de-passe - j'ai opté pour le procédé dit du setuid_bit via la commande préalable :
Bloc de code:
sudo chmod 4755 /usr/bin/tmutil
- le setuid_bit (set_root_user_id_bit) consiste à substituer sur un utilitaire au bit d'exécution standard de l'user (x) le bit exécutif de root_substitué (s) --> ce qui fait que tout déclenchement d'exécution par un utilisateur standard se trouve converti automatiquement en exécution de l'utilitaire sous l'identité de root. Le procédé du setuid_bit économise donc l'emploi de sudo
Donc la commande à exécuter dans le panneau
Cron pour l'utilisateur de «
CronniX» :
passe sans aucune difficulté grâce au
setuid_bit exécutif d'utilisateur fixé sur l'utilitaire qui injecte l'
identité de root à l'exécution.
Afin de pouvoir vérifier où j'en suis de l'accumulation des
snapshots > je me suis fabriqué une petite application avec l'«
Éditeur de Script» qui consiste en la commande suivante :
Bloc de code:
do shell script "tmutil listlocalsnapshots / | open -f"
- il s'agit de l'ordre classique : exécuter le script shell suivant mis entre "" --> le contenu en question consistant dans la commande :
Bloc de code:
tmutil listlocalsnapshots / | open -f
- l'utilitaire tmutil toujours est appelé avec le verbe listlocalsnapshots (lister les snapshots locaux) > le pipe | redirigeant le flux de sortie de cette commande sur l'utilitaire open (ouvrir) accompagné de l'option -f qui signifie : "lire le flux passé en entrée à l'utilitaire et l'ouvrir dans l'éditeur de texte par défaut - càd. «TextEdit»".
un clic sur le raccourci de cette application loggé dans le
Dock affiche directement la liste des
snapshots locaux existants dans une fenêtre de «
TextEdit». Cette commande me permet de vérifier que le
cron horaire est parfaitement fonctionnel et qu'un
shapshot se trouve affiché par heure écoulée.
Ce petit bricolage : prise de
snapshots automatisée > outil d'affichage de la liste fonctionne donc bien.
----------
Pourquoi est-ce que je me suis lancé dans cette opération ? - c'est que plusieurs expérimentations que j'ai effectuées montrent que la technologie du
snapshot apfs fonctionne fantastiquement bien. Exemple : j'arrose mon Bureau de session d'une vingtaine de documents variés > et manuellement pour l'expérience je crée ensuite un
snapshot dont je vérifie qu'il est bien affiché dans la liste. Comme j'ai horreur des Bureaux non-vides > je mets à la corbeille tout le bazar et je la vide.
Je re-démarre par
⌘R en mode
Recovery locale > option :
Récupérer une sauvegarde Time Machine (NB.
TM est désactivé chez moi et je n'ai aucun volume de DDE dédié à une sauvegarde
TM) --> le logiciel m'affiche le volume de mon OS comme disque de
snapshots locaux > je le choisis > et je revois s'afficher la liste de mes
shapshots. Je sélectionne le dernier (effectué avant mise à la corbeille des fichiers du Bureau) et je presse le bouton de récupération. En
une seconde environ l'opération s'effectue et un re-démarrage automatique s'opère sur l'OS --> à l'ouverture de ma session > tous les fichiers précédemment supprimés sont affichés sur le Bureau. Rien n'a donc été perdu.
----------
La question qui se pose alors est la suivante : est-ce que l'accumulation des
snapshots au rythme de
un par heure ne va pas faire pression sur l'occupation du volume ?
Je me suis livré à quelques vérifications > dont il me paraît ressortir ceci -->
- si je passe une commande :
régulière (et en supposant que je n'ajoute pas de fichiers ni n'en supprime dans le volume de l'OS démarré) --> la taille des blocs occupés correspondant au volume reste constante. Dans mon expérience > j'obtiens une valeur de l'ordre de 60 Go.
si je passe une commande :
régulière (toujours à conditions constante de gestion des écritures de fichiers dans le volume de l'OS) --> la
taille mesurée des fichiers du volume
augmente progressivement. Progressivement mais non dramatiquement : j'ai eu l'impression (dans ma configuration du moins) que la taille d'un
snapshot individuel était de l'ordre de
200 Mo environ (quand même ! - ce n'est pas rien...). Donc 24 heures de
snapshots automatiques va donner aux environs de
5 Go > ce qui fait que je vais obtenir une mesure de taille de fichiers de
65 Go environ.
Mais où sont lesdits
snapshots ? - mon enquête précédente m'a montré qu'il ne sont
nulle part dans le périmétre du volume monté sous forme de fichiers identifiables (comme les anciens
snapshots locaux de
Time Machine). Ils relèvent d'une branche de l'
arbre du système de fichiers apfs intitulée : «
arbre de métadonnées de snapshots ». Ce qui est excessivement curieux est le point suivant : l'accumulation des
snapshots ne fait
pas varier l'espace de blocs occupés par des écritures du volume (
60 Go constants) mais
fait augmenter la mesure de la taille des fichiers du volume (
65 Go).
J'ai donc un volume recelant
65 Go en
mesure de fichiers alors que les
blocs écrits sont évalués à
60 Go. Il faut alors admettre que les
5 Go de fichiers excédentaires relèvent du
système de fichiers (inscrit sur l'en-tête de la partition) - système de fichiers capable d'
inflation logique en taille de métadonnées. Cette inflation en taille du système de fichiers se trouve
portée au compte de la quantité de fichiers du volume (ce qui équivaut à une "pression" exercée sur le volume) > sans que cela ne correspondent à la
mesure des blocs portant les écritures spécifiques du volume.
Il y a là-dedans quelque chose d'assez trouble - que, je l'avoue, je n'ai pas tiré bien au clair pour l'instant. Qui semble avoir pour effet un trouble dans la représentation de la taille exacte d'un
Volume APFS.
----------
Comment faire (pratiquement) pour ne pas me laisser déborder par l'accumulation horaire des
snapshots ? Je me suis créé une seconde petite application avec l'«
Éditeur de Script» dont voici la commande interne :
Bloc de code:
do shell script "tmutil thinlocalsnapshots / 1000000000 1"
Comme on nage, avec le
man actuel de
tmutil, dans la confusion la plus fantastique entre options classiques de
Time Machine et options nouvelles de
snapshots apfs, il m'a fallu un peu tâtonner pour distinguer les chiens des chats et voici le sens de la commande :
- le verbe thinlocalsnapshots (amincir les snapshots locaux) est utilisé > avec le point de montage / du volume-Système démarré > une première valeur 1000000000 qui correspond au "montant de la purge à effectuer" (purge amount) calculé en quantité de bytes à purger (1000000000 = 1 Go) > et une seconde valeur 1 qui correspond au degré de l'urgence (urgency : graduable de 1 à 4) à effectuer la purge des bytes
- il faut une large minute pour que la commande prioritaire de purger 1 Go de bytes s'effectue après quoi, si j'active ma petite application listant les snapshots locaux, je m'aperçois qu'un certain nombre ont disparu (environ 5 à 200 Mo chaque). À force de répéter l'action de mon application > j'arrive à ne garder qu'un seul snapshot. Parvenu à ce plancher de purge > je retrouve une congruence entre la mesure de l'occupation des blocs et celle de la taille des fichiers.
----------
Comme les aimables lecteurs de cette prose de fin de semaine l'aperçoivent --> une fantastique confusion règne actuellement sur la question des
snapshots locaux
apfs (le
man de
tmutil étant en-dessous de tout sur la question). Vu les enjeux cruciaux de cette technologie (qui permet en un clin d'œil de restaurer l'état d'un volume en le ramenant au contexte de l'instant T correspondant à un
snapshot) --> je m'étonne qu'aucune application graphique ne soit fournie avec l'OS
High Sierra afin de gérer ces ressources (en intégrant : prise automatique de
snapshots > rythme de la prise > lecture de la "pression" sur le volume en terme de taille de fichiers > procédé de purge des anciens
snapshots).
Parce que, même s'il s'agit comme pour
Time Machine de pouvoir récupérer un état temporel du volume > la technologie mise en œuvre n'a rien à voir et le panneau actuel du logiciel
TM ne permet aucunement de gérer cette technologie. À se demander si ce ne seront pas des développeurs qui viendront proposer des applications de tierce partie pour gérer les
snapshots apfs (un comble, quand même).
