Salut
pcnum
Je pense que
Moon 
t'a répondu sur le « fond du problème » dans son message
#4 dont je recite ici le passage clé :
Time Machine utilise une image disque sparsebundle pour les sauvegardes.
Cette image disque "gonfle" au fur est à mesure que les sauvegardes s'accumulent.
Lorsque Time Machine supprime les sauvegardes horaires puis journalières, l'image disque ne diminue pas en conséquence. D'où cette impression qu'on ne récupère pas la place.
En fait, Time Machine va libérer la place dans l'image disque, place qu'il utilisera jusqu'à saturation et qu'il soit obligé d'augmenter de nouveau sa taille.
Comme je me suis placé ici dans la position du scoliaste > autant donc gloser sur le texte cité
en me cantonnant au fonctionnement logique d'une image-disque de faible densité
SPARSEBUNDLE (pour «
Time Machine» - je passe la main, car je ne l'utilise jamais comme mode de sauvegarde).
Une image-disque est un
disque dur virtuel ou
container-disque qui se comporte comme un disque dur matériel : on y a affaire à un espace disque, décrit par une table de partition
GUID, la partition principale formatée par un système de fichiers
jhfs+ pilotant le montage d'un volume utilisable.
Lorsque l'image-disque en question n'est pas d'un type à t
aille fixe, comme le
DMG, mais est d'un type
SPARSEBUNDLE comme l'image-disque utilisé par «
TimeMachine» > alors on a affaire à une image-disque de «
faible densité ». Ce qui veut dire que le disque virtuel en question possède une taille extensible (étirable)
en fonction de la taille de données qui viennent à être écrites dans son volume monté. 100 Go de données dans le volume ? => disque virtuel
SPARSEBUNDLE de 100 Go. 250 Go de données dans le volume ? => disque virtuel
SPARSEBUNDLE de 250 Go. Bref : un disque virtuel de faible densité
croît en taille de son container en rapport avec la
croissance en taille d'occupation actuelle en données du volume qui monte à partir de lui.
Une disque virtuel de faible densité a une
taille limite d'extension théorique fixée à sa création : par exemple, je peux créer une image-disque
SPARSEBUNDLE de 600 To ( ! ) > 600 To représenteront alors la taille limite théorique de ses possibilités logiques d'extension. Mais, au départ, mon disque virtuel n'occupe pas 600 To > puisqu'il ne s'agit là que d'une limite théorique sans correspondance avec une occupation du volume monté par des données. Le disque virtuel de 600 To d'extension théorique ne "pèsera" en fait (à vide) qu'environ 650 Mo.
Au fur et à mesure que des données vont être écrites
dans le volume qui monte à partir de ce disque virtuel > le disque va
croître en taille effective. Si sa capacité théorique excède très largement la taille de la partition de disque physique qui l'héberge (comme dans mon exemple farfelu d'un
SPARSEBUNDLE de 600 To qui peut très bien être hébergé dans une partition de disque physique de 1 To seulement - n'en occupant au départ que 650 Mo et ne croissant en taille effective qu'en rapport avec les données qui viennent lester son volume monté) > alors les limites du
volume d'hébergement de la partition du disque physique vont être les
limites de capacité d'extension du disque virtuel SPARSEBUNDLE. Parce que, si le
SPARSEBUNDLE est un disque dur virtuel > ce disque dur virtuel ne repose pas "en l'air" > mais son espace de blocs virtuels correspond toujours en dernière instance à un espace-disque physique d'hébergement sur les blocs duquel résident les écritures.
Admettons donc que mon disque virtuel
SPARSEBUNDLE de 600 To théoriques soit hébergé dans une partition de disque physique de 1 To et qu'il serve à des sauvegardes
TM > au fur et à mesure des accumulations d'écritures dans le volume monté > mon
SPARSEBUNDLE a augmenté en taille-disque jusqu'à atteindre les limites de contenance de la partition d'accueil : soit 1 To. Imaginons à présent que, volontairement, je supprime 500 Go de vieilles sauvegardes dans le volume monté de mon
SPARSEBUNDLE > le volume monté ne contient donc plus que 500 Go de données actuelles > eh bien ! le
disque virtuel (ou
container-disque) du
SPARSEBUNDLE qui sert de support de montage à ce volume
ne régresse pas en taille, lui : il va garder strictement la taille maximum atteinte préalablement, soit 1 To dans mon exemple.
En résumé : un
SPARSEBUNDLE est extensible "
en avant" (dans le sens de la
croissance) mais pas "
en arrière" (dans le sens de la
décroissance). Il suit donc l'
augmentation de la taille de données dans le volume monté > mais il ne suit pas une
diminution de la taille des données dans le volume monté. Il y a
asymétrie. Supposons un disque virtuel
SPARSEBUNDLE dont la taille de container-disque a cru en étirement jusqu'à 1 To, parce que 1 To d'écritures ont été faites dans son volume monté > je supprime à présent volontairement toutes ces écritures de 1 To de sorte qu'il n'y a plus que 0 Ko de données dans le volume monté > le container-disque
SPARSEBUNDLE garde la taille maximum atteinte précédemment = 1 To, alors que son volume monté est vide.
