10.13 High Sierra Autres volumes dans le conteneur

Bloc de code:
Last login: Mon Nov 27 22:22:01 on ttys000
macbook-pro-de-donat:~ donat$ diskutil verifyVolume disk1
Started file system verification on disk1
Verifying storage system
Using live mode
Performing fsck_apfs -n -x -l /dev/disk0s2
Checking volume
Checking the container superblock
Checking the EFI jumpstart record
Checking the space manager
Checking the object map
Checking the APFS volume superblock
Checking the object map
Checking the fsroot tree
Checking the snapshot metadata tree
Checking the extent ref tree
Checking the snapshots
Checking the APFS volume superblock
Checking the object map
Checking the fsroot tree
Checking the snapshot metadata tree
Checking the extent ref tree
Checking the snapshots
Checking the APFS volume superblock
Checking the object map
Checking the fsroot tree
Checking the snapshot metadata tree
Checking the extent ref tree
Checking the snapshots
Checking the APFS volume superblock
Checking the object map
Checking the fsroot tree
Checking the snapshot metadata tree
Checking the extent ref tree
Checking the snapshots
Verifying allocated space
warning: Overallocation Detected on Main device: (2319290+1) bitmap address (434771)
The volume /dev/disk0s2 appears to be OK
Storage system check exit code is 0
Finished file system verification on disk1
macbook-pro-de-donat:~ donat$
 
Tu as bien ceci -->
Bloc de code:
Verifying allocated space
warning: Overallocation Detected on Main device: (2319290+1) bitmap address (434771)

  • qui détecte une sur-allocation de blocs.

Pour tenter de réparer le système de fichiers APFS > il faut démarrer par ⌘R en mode Recovery (ce qui est plutôt lent > car les ressources de démarrage du volume Recovery sont clonées en totalité dans une image-disque en RAM > le Mac démarrant donc sur la RAM > ce qui permet une indépendance par rapport au disque total).

Tu peux lancer l'«Utilitaire de Disque» et faire un S.O.S. successivement sur le Conteneur et sur le volume Macintosh HD. De retour dans ta session > vérifier par un :
Bloc de code:
diskutil list
l'espace alloué au volume VM.
 
j'ai ca:
Bloc de code:
Last login: Mon Nov 27 22:52:27 on ttys000
macbook-pro-de-donat:~ donat$ diskutil list
/dev/disk0 (internal):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                         121.3 GB   disk0
   1:                        EFI EFI                     314.6 MB   disk0s1
   2:                 Apple_APFS Container disk1         121.0 GB   disk0s2

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +121.0 GB   disk1
                                 Physical Store disk0s2
   1:                APFS Volume Macintosh HD            111.6 GB   disk1s1
   2:                APFS Volume Preboot                 20.3 MB    disk1s2
   3:                APFS Volume Recovery                520.8 MB   disk1s3
   4:                APFS Volume VM                      1.1 GB     disk1s4

macbook-pro-de-donat:~ donat$
 
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- :coucou: 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.
 
Maco

J'ai passé ces commandes chez moi et elles se sont parfaitement déroulées.
La seule différence est que mon système ne swape pas (mise sur mémoire auxiliaire (disque) d' environnements applicatifs pour libérer de la mémoire "vive" en cas de manque).
Ce swap, très pénalisant en terme de performances, même si le SSD atténue les effets de lenteur et le "ballon de plage" (souris ronde et multicolore) est le fond du problème ici et je parierai que sans tarder la partition VM va "prendre du ventre" en fonction des utilisations.
8 Go de mémoire c'est pas beaucoup et il faudrait analyser l'environnement logiciel.
Pour @Daansh (l'auteur du sujet) c'est encore pire : 1/4 du disque utilisé par la VM.
 
:coucou: Jean

Comme le fichier sleepimage n'est utilisé que lors du passage au sommeil-Système ou à l'hibernation (en fonction du paramétrage des économies d'énergie) --> on peut donc considérer qu'il est inemployé en cours de session.

Restent les fichiers swapfiles : effectivement s'ils sont en cours d'utilisation > cela pourrait expliquer que le kernel ne veuille pas lâcher le chargement du volume ("resource busy").

Je proposerais de passer alors la commande informative :
Bloc de code:
sudo lsof +D /private/var/vm

  • qui retourne la liste des processus en cours d'utilisation du répertoire-cible > ici le sous-dossier vm point de montage du volume VM
 
Je parierai que c'est le kernel qui utilise les swap, car un process ne peut de lui même décider de s'éjecter sur mémoire auxiliaire ou de s'en extraire pour revenir travailler quand on le sollicite.:D
C'est une des "bases de l'informatique d'antan" où la mémoire coutait très cher et l'optimisation se faisait à tout crin.
Il n'empêche que ces "vieilles méthodes" perdurent toujours.
Donc pour connaitre les gros consommateurs de mémoire, ce sont
soit la commande :
top -o mem
soit le moniteur d'activité onglet "Mémoire".
 
À admettre une activité de swap utilisant le volume VM monté at: /private/var/vm ; et sachant que le swap crée des fichiers d'échange swapfiles limités en taille chacun à 1 Go ; alors si le gonflement de VM à 9,7 Go en situation initiale n'avait été que la résultante d'un swap "actuel" --> on aurait dû avoir dans VM le décompte suivant :
Bloc de code:
1,0 G /private/var/vm/sleepimage
1,0 G /private/var/vm/swapfile0
1,0 G /private/var/vm/swapfile2
1,0 G /private/var/vm/swapfile3
1,0 G /private/var/vm/swapfile4
1,0 G /private/var/vm/swapfile5
1,0 G /private/var/vm/swapfile6
1,0 G /private/var/vm/swapfile7
1,0 G /private/var/vm/swapfile8
1,0 G /private/var/vm/swapfile9

Or on n'avait que le décompte suivant attesté par la commande du :
Bloc de code:
1,0 G /private/var/vm/sleepimage
1,0 G /private/var/vm/swapfile0
1,0 G /private/var/vm/swapfile2

soit 3 Go en tout de fichiers > dont 2 Go de fichiers d'échange actuellement utilisés.

Restaient donc 6,7 Go d'occupation de blocs du disque par le volume > ne correspondant à aucun fichier "actuel" recensé.

Je maintiens donc l'erreur d'allocation de blocs par le gestionnaire bitmap du système de fichiers APFS (erreur attestée par la vérification). Suite à la réparation en mode Recovery > on obtient une taille de VM = 1 Go = la seule sleepimage.

Les 2 fichiers swapfiles 1,0 G + 1,0 G ont donc été purgés par la vertu du re-démarrage qui a effacé la RAM > mais les 6,7 Go d'espace bitmap sur-alloué par erreur au volume VM ont aussi été effacés par la réparation.
 
Je n'ai jamais dit qu'il n'y avait pas une erreur d'allocation. La preuve.
J'ai dit que pour moi, le grossissement de la partition VM est inévitable en cas de swap. Après il y a peut être un bug qui empêche l'adaptation de taille de la partition tant que la swap est active.
Un redémarrage sans échecs suffirait peut être à la remettre d'aplomb, à condition que le gestionnaire de la mémoire virtuelle :
/System/Library/LaunchDaemons/com.apple.dynamic_pager.plist ne soit pas lancé.
 
merci bien bien, voilà la commande demandée, j'en profite pour dire que j'ai remarqué une nette amélioration (pour l'instant) quant à l'espace occupé par les "autres volumes" (entre 1,7 et 2,8 G depuis hier)
Bloc de code:
Last login: Tue Nov 28 08:16:37 on console
macbook-pro-de-donat:~ donat$ diskutil verifyVolume disk1
Started file system verification on disk1
Verifying storage system
Using live mode
Performing fsck_apfs -n -x -l /dev/disk0s2
Checking volume
Checking the container superblock
Checking the EFI jumpstart record
Checking the space manager
Checking the object map
Checking the APFS volume superblock
Checking the object map
Checking the fsroot tree
Checking the snapshot metadata tree
Checking the extent ref tree
Checking the snapshots
Checking the APFS volume superblock
Checking the object map
Checking the fsroot tree
Checking the snapshot metadata tree
Checking the extent ref tree
Checking the snapshots
Checking the APFS volume superblock
Checking the object map
Checking the fsroot tree
Checking the snapshot metadata tree
Checking the extent ref tree
Checking the snapshots
Checking the APFS volume superblock
Checking the object map
Checking the fsroot tree
Checking the snapshot metadata tree
Checking the extent ref tree
Checking the snapshots
Verifying allocated space
warning: Overallocation Detected on Main device: (2319290+1) bitmap address (434409)
The volume /dev/disk0s2 appears to be OK
Storage system check exit code is 0
Finished file system verification on disk1
macbook-pro-de-donat:~ donat$
 
Tu as toujours ta sur-allocation :
Bloc de code:
Verifying allocated space
warning: Overallocation Detected on Main device: (2319290+1) bitmap address (434409)
mais il faudrait faire un clean install pour liquider ce problème - sans doute.

Est-ce que tu peux poster le retour d'un :
Bloc de code:
diskutil list

pour qu'on voie ces améliorations d'occupation d'espace ?
 
Bloc de code:
Last login: Tue Nov 28 18:37:11 on ttys000
macbook-pro-de-donat:~ donat$ diskutil list
/dev/disk0 (internal):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                         121.3 GB   disk0
   1:                        EFI EFI                     314.6 MB   disk0s1
   2:                 Apple_APFS Container disk1         121.0 GB   disk0s2

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +121.0 GB   disk1
                                 Physical Store disk0s2
   1:                APFS Volume Macintosh HD            103.1 GB   disk1s1
   2:                APFS Volume Preboot                 20.3 MB    disk1s2
   3:                APFS Volume Recovery                520.8 MB   disk1s3
   4:                APFS Volume VM                      2.1 GB     disk1s4

macbook-pro-de-donat:~ donat$


voilà
 
En effet : c'est dans les valeurs basses par rapport à ce que tu avais.

Pour vérifier l'occupation de VM > passe la commande :
Bloc de code:
sudo du -sh /private/var/vm/*

et poste le tableau, pour voir.
 
On voit surtout que ton SSD est plein à raz bord et que tu devrais faire un peu de place en supprimant les données inutiles ou en les migrant sur un disque externe.;)
 
Bloc de code:
Last login: Tue Nov 28 18:43:53 on ttys000
macbook-pro-de-donat:~ donat$ sudo du -sh /private/var/vm/*
Password:
1,0G    /private/var/vm/sleepimage
1,0G    /private/var/vm/swapfile0
macbook-pro-de-donat:~ donat$

oui le disque dur est bientôt plein mais sans les 12 Gigas qui étaient affichés hier ca va déjà mieux
 
L'espace occupé par le volume VM est désormais identique à la taille des fichiers contenus (2 Go). Donc l'erreur paraît corrigée ici.

Sinon --> même avis que Jean : ton disque a une capacité restreinte et tu n'as que 15 Go de marge d'espace libre dans le Conteneur total. Au lieu de jongler en permanence avec le blocage du volume > tu pourrais déporter des fichiers graphiques sur un DDE.
 
oui oui je m'occupe de ca régulièrement mais il est vrai que là ca va commencer à urger. En tout cas merci beaucoup pour votre aide:merci: