10.13 High Sierra Systeme fichier High Sierra

:coucou: spleen

La conjecture de flags non-libres > qui auraient été purgés par la création d'un nouveau volume avec une taille de réserve substantielle --> n'a pas été confirmée par l'expérimentation.

Un de tes clichés est intéressant > car le sous-titre de la partie grise de la barre mentionne : 2 non monté(s) 204,65 Go.

Or des 5 Volumes présents dans le Conteneur à ce moment-là > les 3 montés étaient : macOS (Système) > Purge (expérimental) > et VM (parce que le dossier vm dans le volume macOS : /private/var/vm lui tient lieu de point de montage --> de telle manière que les contenus de la RAM puissent être écrits à la sleepimage du volume VM monté at vm).

Donc les 2 non-montés qui restent sont : Preboot et Recovery, qui totaliseraient 204,65 Go de taille, alors qu'en mesures analytiques ils font : 42 Mo et 1 Go = 1,4 Go.

Il y a forcément une erreur de fonctionnement du système APFS. Ton dernier cliché me paraît le confirmer :
Bloc de code: 
verifying allocated space
warning: Overallocation Detected on Main Device

Vérification de l'espace alloué --> attention ! allocation excédentaire détectée sur l'appareil principal.

----------

Je pense qu'il faudrait que tu fasses une sauvegarde de tes données > que tu supprimes l'actuel Container APFS de la partition disk0s2 > que tu ré-installes High Sierra en mode APFS > que tu récupères tes données à la fin avec l'«Assistant de migration» à partir de ta sauvegarde.

Pour effacer ton Container APFS > tu peux être démarré sur une clé d'install de High Sierra. Mais j'ai aussi constaté un point marrant : quand tu démarres en mode Recovery de High Sierra (via ⌘R) > il n'y a pas démarrage sur le volume Recovery du Container > mais le dossier démarrable du volume Recovery est cloné à la volée dans un RAMDisk créé spécialement en RAM > de sorte que le Mac démarre sur un Système de secours purement en RAM comme s'il s'agissait d'un démarrage par internet.

La preuve en est fournie par une commande :
Bloc de code: 
hdiutil info
passée dans le «Terminal» du Recovery OS --> le volume principal OS X Base System démarré est déclaré avoir pour support un : //:ramfile (au lieu que soit indiquée l'adresse de la partition du disque) - donc tout est dit.

Donc tu peux aussi bien démarrer en mode Recovery (= en RAM) > effacer le Container APFS y compris le volume Recovery puisque tu seras démarré sur son clone en RAM > puis activer l'option : Ré-installer macOS à destination du volume JHFS+ standard issu de la suppression.

Pour supprimer via le «Terminal» > c'est la commande :
Bloc de code: 
diskutil ap deleteContainer disk1 macOS

  • tu passes un diskutil list préalable pour t'assurer que le disque du Container est bien disk1 et n'a pas été décalé en queue de liste des devices - auquel cas tu changes son n° de disque ; la mention macOS en fin de commande - en fait un nom quelconque - permet de donner un intitulé préférentiel au volume JHFS+ de sortie.

----------

Notes : personnellement > je trouve toujours assez ennuyeux d'avoir à attendre tout le temps du téléchargement des ressources d'un OS sans pouvoir me servir de mon Mac (ce qui est le cas avec l'option : Ré-installer macOS). De plus > on dépend toujours du serveur de l'AppStore pour obtenir le paquet.

Pour ce qui est du Recovery cloné intégralement en RAM > je ne connais qu'un cas antérieur : c'est l'OS «Yosemite» > où le démarrage en mode Recovery en principe local > suscitait un clonage en RAM du dossier de secours de la Recovery HD. Je n'ai jamais su si c'était voulu délibérément ou pas. Dangereux quand même > si l'utilisateur redémarrait après avoir effacé son disque. Il a supprimé le Recovery original et effacé de la RAM le clone. L'actuelle possibilié de démarrer par internet via ⌘⌥R afin de pouvoir ré-installer le plus récent OS public sert de filet de sécurité maintenant.
 
:coucou: Madalvée

10 Go purgeables : ce n'est pas assez pour être responsable de ton problème d'espace sur-occupé. Tu as peut-être un problème analogue à celui de spleen.

Tu peux dans le «Terminal» passer les 3 commandes :
Bloc de code: 
diskutil list
df -H /
diskutil verifyVolume /

  • la 1ère liste les disques et partitions
  • la 2è > les espaces : total > libre > occupé pour le volume démarré
  • la 3è vérifie en mode live (petit gel momentané) le système de fichiers APFS du volume démarré

=> tu n'as qu'à poster tout ce bazar ici - de préférence en copier-coller dans une fenêtre de code. Pour cela --> presse le bouton ⌹ (4è avant la fin à droite) dans la barre de menus au-dessus du champ de saisie d'un message > menu : </> Code > par ⌘V colle dans la fenêtre Code > presse le bouton Insérer (ce procédé permet un affichage fenêtré qui économise l'espace de page en respectant la mise en forme des tableaux du «Terminal» --> d'où une plus grande lisibilité).
 
Pendant que tu écrivais, je rebootais réinitialisant la NVRAM/PRAM et testant diverses commandes via le terminal de la Recovery. Je me disais justement que je n'aurais pas le choix de la réinstallation. J'ai déjà un clone CCC, je ne peux pas en profiter en supprimant le disk1 défectueux à partir du clone et en tentant une restauration ?
 
macomaniac a dit:
:coucou: Madalvée

10 Go purgeables : ce n'est pas assez pour être responsable de ton problème d'espace sur-occupé. Tu as peut-être un problème analogue à celui de spleen.

Tu peux dans le «Terminal» passer les 3 commandes :
Bloc de code: 
diskutil list
df -H /
diskutil verifyVolume /

  • la 1ère liste les disques et partitions
  • la 2è > les espaces : total > libre > occupé pour le volume démarré
  • la 3è vérifie en mode live (petit gel momentané) le système de fichiers APFS du volume démarré

=> tu n'as qu'à poster tout ce bazar ici - de préférence en copier-coller dans une fenêtre de code. Pour cela --> presse le bouton ⌹ (4è avant la fin à droite) dans la barre de menus au-dessus du champ de saisie d'un message > menu : </> Code > par ⌘V colle dans la fenêtre Code > presse le bouton Insérer (ce procédé permet un affichage fenêtré qui économise l'espace de page en respectant la mise en forme des tableaux du «Terminal» --> d'où une plus grande lisibilité).
Cliquez pour agrandir...

Le situation s'est normalisée après le scan que tu m'as demandé, le finder affiche le bon espace libre… Le refresh du finder a suivi. Les joies d'un système en .0, tant qu'il retombe sur ses pattes c'est l'essentiel.
 
@ spleen

Tu peux démarrer sur ton clone supprimer le Container disk1 juché sur la partition disk0s2. Mais si tu clones à rebours directement après ça > «CCC» va cloner dans le volume JHFS+ remonté après la suppression du Container et tu auras un High Sierra de type JHFS+. Il faudrait alors que tu ré-appliques un installateur de High Sierra pour opérer la conversion APFS.

Ou que tu re-télécharges un installateur de High Sierra et que tu le copies dans le volume de ton clone. Ainsi > tu pourrais après la suppression du Container le lancer > pour qu'il recrée un Container et ré-installe High Sierra > et à la fin tu pourrais utiliser la migration depuis ton clone.

-----------

Je n'ai pas testé la possibilité (qui serait de toutes la plus simple) -->

depuis le clone > dans le «Terminal» supprimer le Container actuel > et en recréer un par une série de commandes du type suivant :
Bloc de code: 
diskutil ap create disk0s2 macOS

  • qui recrée un Container APFS sur disk0s2 avec un volume principal macOS

Bloc de code: 
diskutil ap addVolume disk3 apfs Preboot -role B
diskutil ap addVolume disk3 apfs Recovery -role R
diskutil ap addVolume disk3 apfs VM -role V

  • qui crée les 3 autres volumes réguliers avec leurs noms et le flag de leur role logique (important !) : B (pour volume PreBoot) > R (por volume Recovery) > V (pour volume VM) - flag leur empêchant notamment d'être montés automatiquement mais aussi leur assignant leur fonction logique dans le Container.

  • j'ai mis disk3 por le nouveau Container > car disk0 étant le disque interne > disk1 l'ancien Container dont le kernel a dû conserver le n° de device > disk2 le disque supportant le clone > reste disk3 pour le n° (en kernel - s'il ne s'est pas mis à jour des disques) du nouveau Container. Tu vérifies bien sûr par un diskutil list préalable mes élucubrations.

=> cloner via «CCC» à destination du volume macOS principal serait une manière décisive de tester le nouveau «CCC 5» --> s'il est capable aussi de mettre à jour le volume Preboot (vide) assigné au role B et le volume Recovery (vide) assigné au role R (le volume VM n'a pas d'importance ici). J'ai pu voir que «CCC» archive bien, dans son dossier (dans le volume du clone -->) /Library/Application Support/com.bombich.ccc > un dossier PreBoot et un dossier Recovery. Comme Bombich déclare que son logiciel est prêt pour l'APFS > c'est donc qu'il doit savoir recloner aussi les volumes Preboot et Recovery d'un Container d'accueil - pour autant que ces volumes y pré-existent avec les bons noms et rôles.

Je n'ai pas testé si, étant donné un Container APFS avec le seul volume principal présent > «CCC» est capable de pré-créer les 3 volumes manquants (Preboot > Recovery > VM) avant de mettre à jour les 2 premiers. Je ne pense pas qu'il sache générer un Container APFS s'il n'y a qu'un volume JHFS+ en accueil.
 
@ Madalvée

Il devait y avoir une erreur mineure dans le système de fichiers du volume démarré et la simple vérification a dû avoir un effet de correction. J'ai l'impression qu'on va se payer pas mal d'anicroches de ce type en début de développement de l'OS.

Sinon > il est impossible de réparer en mode live (le volume démarré impliqué laissé monté) > il faut démarrer en mode Recovery > «Utilitaire de Disque» > sélection du volume > S.O.S.
 
Bonsoir, juste une question à ceux qui peuvent utiliser leur partition de boot avec APFS:

On sait que ce système de fichier créé des alias si on duplique le fichier (donc ça ne prend pas 2X plus de place), et seulement les modifications différentes que l'on fait sur la copie prennent de la place (J'ai juste pour le moment?).

Par contre comment cet espace utilisé est-il indiqué lorsqu'on fait un "cmd+1" sur le fichier dupliqué? Est-ce qu'il est indiqué la taille réelle (qqe ko/mo pour un fichier lourd non modifé depuis la copie) - mais dans ce cas il y aurait donc un fichier "principal"?

Ou est-ce que c'est la taille théorique, qui fait que si on regarde la taille du dossier dans lequel se trouve ce fichier, est plus faible? Ou bien est-ce qu'il y a 2 indications de taille?


Merci de m'éclairer là-dessus
 
Salut mat

En ce qui me concerne, ça reste inscrutable.

Je viens de faire un essai : création d'un dossier Sans titre vide sur mon Bureau de session de High Sierra --> taille = 0 Ko (⌘I sur le dossier).

J'y déplace un fichier-photo de 2,3 Mo (⌘I sur le fichier) --> ce qui donne une taille du dossier de 2,3 Mo (⌘I sur le dossier).

Je crée un double par ⌘D de ce fichier dans le dossier Sans titre --> taille du fichier duplicata = 2,3 Mo (⌘I sur le nouveau fichier) --> nouvelle taille du dossier = 4,6 Mo (⌘I sur le dossier Sans titre).

=> je ne vois rien de changé.
 
macomaniac a dit:
Salut mat

En ce qui me concerne, ça reste inscrutable.

Je viens de faire un essai : création d'un dossier Sans titre vide sur mon Bureau de session de High Sierra --> taille = 0 Ko (⌘I sur le dossier).

J'y déplace un fichier-photo de 2,3 Mo (⌘I sur le fichier) --> ce qui donne une taille du dossier de 2,3 Mo (⌘I sur le dossier).

Je crée un double par ⌘D de ce fichier dans le dossier Sans titre --> taille du fichier duplicata = 2,3 Mo (⌘I sur le nouveau fichier) --> nouvelle taille du dossier = 4,6 Mo (⌘I sur le dossier Sans titre).

=> je ne vois rien de changé.
Cliquez pour agrandir...

Merci pour ta réponse ! C'est bien ce qu'il me semblait avoir vu dans une vidéo. Mais ça veut dire qu'on ne sait jamais la taille réelle que prend un dossier sur le disque dur (et jamais combien on va gagner en en mettant un à la corbeille)? Ou ils semblent avoir retiré cette fonctionnalité d'alias d'APFS ?

Je sais pas si tu pourras (ou qqn d'autre qui a fait des tests) m'aider là-dessus, mais je demande quand même [emoji6]
 
Salut @macomaniac le sage,

Je suis donc de retour pour des nouvelles. J'ai tenté l'Aventure :
  • J'ai démarré sur la Recovery ;
  • J'ai effacé la partition macOS principale une 1ère fois en APFS : les "autres volumes" (presque des fantômes d'ailleurs) ne voulaient pas quitter les lieux ;
  • J'ai donc formaté une nouvelle fois en FAT32 puis à nouveau en APFS, cette fois-ci j'en ai été libéré !
  • J'ai lancé un disktutil et un fsck : tout était correct cette fois ;
  • J'ai rebooté sur mon Clone et lancé une restauration (CCC5 propose d'ailleurs de lui-même une restauration guidée très sympathique) ;
  • Et après plusieurs heures et un reboot sur la partition principale macOS TADAM !

Screenshot 2017-10-01 à 11.03.46.webp

Note de la modération : modification image faite
 
Dernière édition par un modérateur:
@SpleenXXX
Dans ta réponse pour insérer une image/photo depuis ton Mac, un clic sur Transférer un fichier, tu sélectionnes ton image/photo et tu valides ta réponse. En choisissant miniature, un simple clic dessus l'agrandira. J'ai fait la modification pour toi. ;)
 
Bonjour Modo,
Oui mais du coup on ne voit plus mon screenshot là... je l'ai donc remis ! (ça bug énormément cette balise IMG sur macG, impossible de le faire ici oO !)

Screenshot 2017-10-01 à 11.58.22.webp

Note de la modération : négatif, ça fonctionne très bien. Il faut lire les réponses et mettre en application.
 
Dernière édition par un modérateur:
Ton problème d'excès d'allocation d'espace dans le Conteneur APFS est donc réglé à présent ?

Quand tu dis que tu as formaté en FAT-32 > puis APFS --> tu parles de la partition disk0s2 du disque où résidait le Conteneur global ? --> tu as donc effacé le Conteneur et tu en as recréé un neuf avec un seul volume APFS inclus = macOS ?

Si c'est bien le cas > est-ce que «CCC» t'a recréé les 3 autres volumes ?

Que donnent les 2 commandes :
Bloc de code: 
diskutil list
diskutil ap list
actuellement ?
 
macomaniac a dit:
Ton problème d'excès d'allocation d'espace dans le Conteneur APFS est donc réglé à présent ?

Quand tu dis que tu as formaté en FAT-32 > puis APFS --> tu parles de la partition disk0s2 du disque où résidait le Conteneur global ? --> tu as donc effacé le Conteneur et tu en as recréé un neuf avec un seul volume APFS inclus = macOS ?

Si c'est bien le cas > est-ce que «CCC» t'a recréé les 3 autres volumes ?

Que donnent les 2 commandes :
Bloc de code: 
diskutil list
diskutil ap list
actuellement ?
Cliquez pour agrandir...
Tout à fait ! Tout le conteneur y ait passé ! Et apparemment CCC a retrouvé ces petits (rapport à la VM/Preboot vide).
(Bon la balise IMG est totalement buggé chez moi, donc désolé monsieur le modo) : (partition macOS en cours de chiffrement filevault)

Screenshot 2017-10-01 à 12.08.49.webp

Note de la modération : modification image faite
 
Dernière édition par un modérateur:
Donc tout est rentré dans l'ordre : l'allocation d'espace dans le Conteneur correspond bien à la somme des tailles des 4 volumes. Il y avait manifestement une erreur dans le fichier d'allocation des blocs du système de fichiers APFS. Fichier qui allouait 125 Go environ de blocs à un statut "occupé par des fichiers", sans que ces blocs ne correspondent à aucun volume. Je pense que ça correspond à ma conjecture des flags "non-libres" - sauf qu'ils n'étaient pas purgeables (volatiles) : ils étaient bel et bien attribués faussement de manière fixe par une erreur dans ledit fichier. Fichier irréparable. Donc il fallait effacer le système de fichiers et en recréer un neuf.

Et si je comprends bien > n'ayant recréé qu'un Conteneur vide avec le seul volume macOS > «CCC» t'a fait grâcieusement cadeau de la génération des 3 autres volumes et de leur mise-à-jour par les contenus clonés correspondants. Sacré Bombich ! je suis sûr que même quand il dort, il est en train d'inventer de nouvelles astuces pour son logiciel (qui croirait à un tel sérieux, à voir sa mine de playboy ?).

J'ai découvert ce matin (grâce à un autre fil) une astuce du nouvel «Utiltaire de Disque» de High Sierra : il y a tout à gauche de la barre de menus du panneau du logiciel > un nouveau menu Présentation. Il suffit de cliquer son onglet pour avoir le choix --> Afficher uniquement les volumes vs Afficher tous les appareils. Dans ce dernier cas > tu vois s'afficher le disque physique support > avec le Conteneur APFS en alinéa > et son volume principal en sous-alinéa (les 3 volumes invisibles ne sont pas affichés). Je pense que ton option était par défaut sur : Afficher uniquement les volumes --> ce qui t'a obligé à ruser ; sinon, avec Afficher tous les appareils --> tu aurais pu sélectionner le Conteneur comme objet afin de l'effacer.
 
macomaniac a dit:
Donc tout est rentré dans l'ordre : l'allocation d'espace dans le Conteneur correspond bien à la somme des tailles des 4 volumes. Il y avait manifestement une erreur dans le fichier d'allocation des blocs du système de fichiers APFS. Fichier qui allouait 125 Go environ de blocs à un statut "occupé par des fichiers", sans que ces blocs ne correspondent à aucun volume. Je pense que ça correspond à ma conjecture des flags "non-libres" - sauf qu'ils n'étaient pas purgeables (volatiles) : ils étaient bel et bien attribués faussement de manière fixe par une erreur dans ledit fichier. Fichier irréparable. Donc il fallait effacer le système de fichiers et en recréer un neuf.

Et si je comprends bien > n'ayant recréé qu'un Conteneur vide avec le seul volume macOS > «CCC» t'a fait grâcieusement cadeau de la génération des 3 autres volumes et de leur mise-à-jour par les contenus clonés correspondants. Sacré Bombich ! je suis sûr que même quand il dort, il est en train d'inventer de nouvelles astuces pour son logiciel (qui croirait à un tel sérieux, à voir sa mine de playboy ?).

J'ai découvert ce matin (grâce à un autre fil) une astuce du nouvel «Utiltaire de Disque» de High Sierra : il y a tout à gauche de la barre de menus du panneau du logiciel > un nouveau menu Présentation. Il suffit de cliquer son onglet pour avoir le choix --> Afficher uniquement les volumes vs Afficher tous les appareils. Dans ce dernier cas > tu vois s'afficher le disque physique support > avec le Conteneur APFS en alinéa > et son volume principal en sous-alinéa (les 3 volumes invisibles ne sont pas affichés). Je pense que ton option était par défaut sur : Afficher uniquement les volumes --> ce qui t'a obligé à ruser ; sinon, avec Afficher tous les appareils --> tu aurais pu sélectionner le Conteneur comme objet afin de l'effacer.
Cliquez pour agrandir...

Je pense que c'est l'explication la plus sensée. Maintenant, j'ai peur qu'on ne sache jamais le fin mot de l'histoire...
Lorsqu'on efface puis recréer un conteneur APFS, il ne recrée pas de volumes annexes vides ? (VM/Recovery/Preboot) Dans ce cas CCC, les mets "seulement" à jour.
Nono je suis tombé aussi sur cette nouvelle option et j'ai de suite affiché tous les volumes (cf mes premiers screenshots) (https://cl.ly/mnpc). Je préfère voir la saleté que la nier ^^
 
Au passage, lorsque vous bootez sur votre clone pour restaurer votre système, je recommande le mode sans échec qui fait gagner du temps ;)

Note de la modération : il serait souhaitable de mettre un lien direct officiel de chez Apple et pas une redirection.
 
Dernière édition par un modérateur:

Sujets similaires

M
10.13 High Sierra mise à jour hight sierra
Réponses
6
Affichages
299
macOS
Mobelator
M
D
10.13 High Sierra grisbi high sierra
Réponses
13
Affichages
326
macOS
boninmi
boninmi
E
10.13 High Sierra Mise à jour macOS impossible
Réponses
41
Affichages
1K
macOS
Elgibo
E
The Jibest
10.13 High Sierra Comment supprimer la proposition de M/J vers Mojave sur un Mac incompatible ?
Réponses
5
Affichages
321
macOS
The Jibest
The Jibest
V
10.13 High Sierra Pas de contact ni calendrier dans compte internet
Réponses
1
Affichages
260
macOS
lepetitpiero
lepetitpiero
Haut Bas