Comme tu peux le voir --> la
surallocation de blocs au volume
VM a été
réparée > puisque sa taille n'est plus évaluée, en mode "occapation de blocs" (
carte bitmap), qu'à
1 Go. Soit la taille du fichier
sleepimage chez toi.
Tu noteras par contre que la
taille du volume Macintosh HD a été aussi révisée à la
hausse =
111,6 Go > au lieu des
106,2 Go de l'évaluation initiale de
diskutil > et des
103 Go de la mesure par l'utilitaire
du. Toutes ces variations me semblent montrer le caractère sévèrement
bogué, à l'heure actuelle, de l'OS
High Sierra version
APFS.
J'aimerais que tu repasses une commande de
vérification du système de fichiers-racine du
Conteneur (ce qui va aussi vérifier les 4
embranchements de systèmes de fichiers dérivés des volumes) -->
Bloc de code:
diskutil verifyVolume disk1
et que tu postes ici le retour --> histoire de voir s'il y a toujours un erreur de
carte bitmap (ce qui est conjecturable).
----------
Ce fil a pris une certaine dimension de complexité par l'alternance des messages et des perspectives entre
Jean- 
et mézigue. Mais je ne trouve pas que ça ait nui à cet espace pour la raison suivante : on n'est pas ici dans un fil de "sauvetage" (genre : quelqu'un qui ne peut plus démarrer son Mac sur un OS) si bien qu'une espèce d'urgence pénible fait pression sur les ingerventions > au contraire : l'OS ici fonctionne > et le problème soulevé est de l'ordre d'une optimisation (de l'espace-disque). Ce qui permet une approche assez « euristique » et détendue, plusieurs pistes s'explorant en parallèle pour donner au fil l'allure d'un laboratoire expérimental.
Ce qui me permet de revenir de manière décontractée (en "bras de chemise" ou en mode "théorique" - ce qui est au fond synonyme) sur le procédé décrit par
Jean au message
#14. Avec une paire de commandes :
Bloc de code:
diskutil ap deletevolume disk1s4
diskutil ap addvolume disk1 APFS VM -role V
il proposait astucieusement de
supprimer le volume
VM du
Conteneur APFS > puis de
recréer un volume vide du même nom > l'option
-role V (avec une majuscule à
V comme
VM) étant destinée à
fixer sur le volume un flag (marqueur) l'assignant à la
fonction de volume de stockage des composants de la mémoire virtuelle (fichier
sleepimage et
swapfiles éventuels) : càd. à une
fonction auxiliaire spécifique pour le volume principal Macintosh HD > dont la conséquence est que le volume en question est
monté au démarrage au
point de montage :
/private/var/vm dans le volume démarré de l'OS.
Je pense que cette paire de commandes devrait être passée en mode
Recovery > le volume de l'OS n'étant
pas démarré > et le volume auxiliaire
VM n'étant donc
pas monté à un point de son arborescence.
Car voici mon interprétation du message d'erreur obtenu par
hpetit quand il a passé la 1ère commande (de destruction du volume) dans le
Terminal de l'OS démarré :
Bloc de code:
" The volume "VM" on disk1s4 couldn't be unmounted because it is in use by process 0 (kernel)
Error: -69888: Couldn't unmount disk "
Le volume "VM" monté sur la partition disk1s4 n'a pas pu être démonté, parce qu'il est en cours d'utilisation par le processus 0 ou processus du kernel (= "kernel_task").
Erreur n° machin : le volume n'a pas pu être démonté.
Il faut savoir que le
démontage d'un volume, conduisant à la
désactivation de son système de fichiers-racine, est la
condition préalable d'une
suppression. On ne tranche pas dans le vif, mais dans l'endormi - en somme.
Il faut savoir encore que les volumes ne
montent pas "tout seuls" comme les bulles s'élèvent dans la limonade. Dans le
temps de la session d'utilisateur --> c'est toujours le
kernel démarré qui
monte les volumes sur les partitions > dès lors que le service
diskarbitrationd, probation faite du système de fichiers racine du volume, lui en refile la tâche.
La conséquence en est que tous les volumes
montés (sauf le volume démarré) ont été
montés par le
kernel de l'OS. Ils ont été montés mais ils
ne restent pas montés comme de petites montgolfières qui voltigent en l'air par l'effet d'un gaz ascensionnel. Ils sont
supportés à l'état "monté" «
en_kernel » - càd. "
chargés" continûment par le
kernel en tant qu'expansions logiques des partitions.
En ce sens > tous les volumes montés peuvent être considérés comme «
in use by process 0 (kernel) » : càd.
supportés en kernel par un
processus de chargement. Ce qui ne signifie pas qu'une opération particulière se trouve adressée à un contenu du volume (un fichier par exemple).
La question "théorique" devient alors : pourquoi le
kernel a-t-il refusé de l
âcher le chargement du volume VM (càd. de le laisser s'écraser - pschuttt !... - comme un ballon qui se dégonfle) ?
- est-ce que c'est (il me semble que c'était la conjecture de Jean) parce que tel fichier swapfile se trouvait utilisé par un processus actif de swap) ?
- est-ce que c'est (ce que j'envisageais vaguement pour ma part) parce que le volume VM une fois monté se trouve faire l'objet d'une attention spéciale permanente d'un service (daemon) de l'OS - qui serait chargé de surveiller les actes opérés à son espace - comme l'archivage du contexte de la RAM à la sleepimage ?
=> j'avoue que sur la question j'en reste ici à des points d'interrogation.
