M
Membre supprimé 1060554
Invité
L'occupation (en terme de blocs) de l'espace du Conteneur équivaut à la somme des occupations de ses volumes. Soit 67,8 Go sur 499,4 Go de capacité => ce qui laisse 431,6 Go d'espace libre.
Afin de vérifier si le cas de figure que je viens de te décrire s'applique à ton Conteneur > passe la commande :
Obtiens-tu un retour de cette commande ?
- de quoi permettre "théoriquement" un repartitionnement. Je dis "théoriquement" > car il se pourrait qu'existent des snapshots (instantanés apfs archivant des états passés du volume et verrouillant tous les blocs correspondant aux fichiers des états sauvegardés) > verrouillant comme occupés des blocs situés en queue d'espace du Conteneur. Or un repartitionnement implique de disposer d'une bande continue d'espace libre en bas de l'espace du volume ou du Conteneur impliqué. Quand des blocs écrits se trouvent mal placés en queue d'espace > un mécanisme automatique de clonage des écritures de ces blocs mal placés sur des blocs situés plus en tête de l'espace s'effectue > avant effacement des blocs mal placés en queue => ce qui libère la bande continue d'espace libre nécessaire. Or : si des snapshots existent verrouillant des blocs de queue => ce mécanisme de clonage libératoire se trouve bloqué. Donc tu peux avoir 431 Go d'espace libre théorique et ne pas pouvoir repartitionner ton Conteneur ne serait-ce que de 5 Go.
Afin de vérifier si le cas de figure que je viens de te décrire s'applique à ton Conteneur > passe la commande :
Bloc de code:
diskutil ap listSnaps disk1s1
- qui affiche les snapshots associés au volume-Données (et valant aussi pour le volume-Système appairé)
Obtiens-tu un retour de cette commande ?