10.13 High Sierra Systeme fichier High Sierra

[frandup14]

Bonjour

Je viens d installer High Sierra, mais il ne m a pas proposé l option pour le nouveau systeme de fichier

Comment activer cette option ??

Merci

Voir la pièce jointe 114643

Bonjour,

Je vis un peu la même mésaventure.
J'ai formaté à blanc un disque dur externe de 1To sous Sierra => format Mac OS étendu (journalisé).
Ensuite, j'ai installé dessus Mac OS High Sierra. Tout marche ± bien.
La mise à jour s'est faite ce matin :

Quand je démarre sur la partition de secours de ce disque dur (Apple Boot Recovery => Mac OS 10.13 réduit), l'utilitaire de disque me propose bien d'effacer la partition principale sur laquelle il y a Mac OS High Sierra mais je ne trouve pas l'option pour passer au nouveau système Apple File System (APFS).

J'ai suivi les doctes instructions auxquelles je n'ai pas tout compris et j'obtiens ceci dans le Terminal :

Last login: Wed Jul 26 08:59:46 on console
imac-27-fd-2:~ frandup$ diskutil list

/dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *1.1 TB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_HFS Macintosh HD 1.0 TB disk0s2
3: Apple_Boot Recovery HD 650.0 MB disk0s3

/dev/disk1 (internal):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme 24.0 GB disk1
1: EFI EFI 314.6 MB disk1s1
2: Apple_HFS SSD 25Go 23.6 GB disk1s2

/dev/disk2 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *1.0 TB disk2
1: EFI EFI 209.7 MB disk2s1
2: Apple_HFS Essais 999.3 GB disk2s2
3: Apple_Boot Recovery HD 650.0 MB disk2s3

imac-27-fd-2:~ frandup$ diskutil cs list
No CoreStorage logical volume groups found
imac-27-fd-2:~ frandup$
imac-27-fd-2:~ frandup$ diskutil ap list
No APFS Containers found
imac-27-fd-2:~ frandup$ ​

Est-ce que quelqu'un peut m'indiquer comment transformer le format de fichiers ce disque dur externe en APFS sans tout effacer ?
Merci beaucoup par avance.

Je viens d installer High Sierra, mais il ne m a pas proposé l option pour le nouveau systeme de fichier

Comment activer cette option ??

Merci

Voir la pièce jointe 114643[/QUOTE]

 

[Membre supprimé 1060554]

Salut frandup

Je viens d installer High Sierra, mais il ne m a pas proposé l option pour le nouveau systeme de fichier

Parce que le support est un disque à plateaux : dans l'état actuel du développement de High Sierra > l'option "Convertir à l'APFS" n'est pas proposée dans ce cas de figure.

D'après ton tableau > je présume que la partition concernée est la suivante :

2:      Apple_HFS Essais       999.3 GB   disk2s2

• Même si ce n'est pas ton OS régulier mais un expérimental > tu dois savoir que la conversion à l'APFS > préservatrice des données dans ce sens-là > n'est pas, vice-versa, réversible d'une manière non-desructrice du contenu du volume impliqué comme l'est un système de stockage CoreStorage.

• Il faut savoir encore que la conversion d'un volume JHFS+ à un volume APFS n'est pas supportée en mode '"live" (l'OS du volume concerné démarré et son volume conservé monté pendant l'opération) > mais exige un démontage du volume-cible. Dans ton cas de figure > il te faut donc opérer à partir d'un démarrage sur le Recovery OS 10.13 afin que le volume Essais puisse être démonté.

Pour réaliser ton opération > démarre donc ton Mac la touche "alt" pressée > choisis à l'écran du boot_manager le volume Récupération 10.13 > dans l'interface d'accueil va à la barre de menus supérieure de l'écran > menu Utilitaires > sous-menu Terminal.

Dans la fenêtre du «Terminal» > passe la commande :

diskutil ap convert /Volumes/Essais

Si l'opération est supportée > tu devrais obtenir un affichage du type suivant :

-bash-3.2# diskutil ap convert /Volumes/Essais
Started APFS operation on disk2s2 Essais
Converting HFS Volume to an APFS Container which exports one APFS Volume
The target is the Journaled HFS+ volume Essais backed by the GPT partition disk2s2
Found APFS EFI driver /usr/standalone/i386/apfs.efi to install into the APFS Container
Unmounting disk2s2
Starting conversion from HFS to APFS
Performing apfs_hfs_convert -x --verbose=0x400 --efi /usr/standalone/i386/apfs.efi /dev/disk2s2
Reporting pre-conversion statistics
Reporting post-conversion statistics
Successfully finished conversion from HFS to APFS
Successful conversion in commit mode so will switch type to APFS
Setting type of disk2s2 to APFS
Changing the physical disk partition type in shared mode
Partition modification attempt count was 1
Opening and closing disk2s2 to terminate old content driver
Successfully opened and closed
Expecting the new APFS Container at Physical Store disk2s2
Confirmed existence of new unencrypted APFS Volume disk23s1
Mounting APFS Volume disk23s1
APFS Volume mount attempt result was 0
Exiting conversion operations with error code 0
Disk from APFS operation: disk23s1
Finished APFS operation on disk2s2 Essais
-bash-3.2#

=> si tu n'obtiens pas de message d'erreur > ton volume Essais devrait avoir été viré au statut APFS. Tu n'as qu'à re-démarrer sur ce volume > et dans le «Terminal» de son OS passer la commande :

diskutil list

Le retour concernant le disque 2 devrait avoir changé à quelque chose du type :

/dev/disk2 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 7B     disk2
   1:                        EFI EFI                     209.7 MB   disk2s1
   2:                 Apple_APFS Container disk3         999.3 GB   disk2s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk2s3
 
/dev/disk3 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +999.3 GB   disk3
                                 Physical Store disk2s2
   1:                APFS Volume Essais                  XX.0 GB    disk3s1
   2:                APFS Volume Preboot                 20.8 MB    disk3s2
   3:                APFS Volume Recovery                520.2 MB   disk3s3
   4:                APFS Volume VM                      8.6 GB     disk3s4

(avec des variations de détails que ne n'anticipe pas)

- je conjecture qu'il y aura toujours la partition :

   3:                 Apple_Boot Recovery HD             650.0 MB   disk2s3

pour la raison qu'elle existait préalablement à la conversion et que tu étais démarré sur son Recovery OS (ce qui la rendait non supprimable) > mais tu noteras que désormais la vraie Recovery du volume APFS Essais est le volume APFS :

   3:                APFS Volume Recovery                520.2 MB   disk3s3

qui ne relève plus d'une partition Recovery HD spécifique > mais est un volume logique du Container APFS global.

 

[SpleenXXX]

Bonjour,

Qu'est-ce que signifie "Autres Volumes" ? Diskutil n'en fait pas mention... →



Note de la modération : modification image faite

 

[Membre supprimé 1060554]

Bonjour Spleen

Tu as un disque interne de 500 Go qui est tri-partitionné : partition n°1 (disk0s1) = EFI de 209 Mo (petite partition inaugurale créée par défaut avec une table de partition GUID) > partition n°2 (disk0s2) = macOS de 385 Go (partition de High Sierra) > partition n°3 (disk0s3) = Windows de 114 Go (partition de W-10).

La partition disk0s2 de 385 Go a été convertie par l'APFS au statut de Physical Store = magasin de stockage physique. Ce magasin de stockage de la partition sert de fondation physique (de backup de données) à un Conteneur APFS. Ce Conteneur est comme une espèce de "boîte" logique (un ensemble) comportant 4 objets qui sont des Volumes APFS -->

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +385.7 GB   disk1
                                 Physical Store disk0s2
   1:                APFS Volume macOS                   215.1 GB   disk1s1
   2:                APFS Volume Preboot                 41.9 MB    disk1s2
   3:                APFS Volume Recovery                1.0 GB     disk1s3
   4:                APFS Volume VM                      2.1 GB     disk1s4

Cette distribution de 4 Volumes APFS dans la "boîte logique" du Conteneur APFS est la distribution par défaut --> macOS = le volume de High Sierra > Preboot = le volume de pré-démarrage de macOS --> Recovery = le volume du Système de secours --> VM (Virtual Memory) = le volume qui recèle la sleepimage (fichier où se sauvegardent les contenus de la RAM avant mise-en-sommeil du Système).

Étant donné ce contexte que je viens de brosser > quand tu demandes :

Qu'est-ce que signifie "Autres Volumes" ?

le terme "Autres Volumes" désigne les 3 autres Volumes APFS contenus dans la même "boîte" logique du Conteneur APFS que le volume macOS. En somme : les volumes comparses, que tu ne vois pas parce qu'ils ne sont pas montés par défaut après que tu sois démarré sur macOS.

Si tu créais un nouveau Volume APFS (un 5è) dans le Conteneur APFS (ce qui est entièrement possible) --> alors ce nouveau volume serait lui monté visiblement en même temps que macOS et pourrait servir à stocker des données ou à installer un 2è OS High Sierra (ou à receler un clone de macOS éventuellement).

Intrinsèquement > le système de stockage APFS fait qu'aucun volume n'a une taille prédéfinie (à moins qu'à sa création on n'ait opté pour une taille de réserve déterminée - ce qui n'est pas le cas par défaut), mais n'a que la taille actuelle de ses données. Sa taille maximale est assignée par la taille du Conteneur APFS qui comprend ce volume > taille du Conteneur APFS elle-même déterminée par le Physical Store (magasin de stockage physique) inscrit sur la partition disk0s2 du disque.

L'expansion d'un volume macOS de sa taille actuelle en données vers la limite assignée par la taille du Conteneur APFS global > est "concurrencée" à l'intérieur du Conteneur APFS par l'existence des autres Volumes APFS - lesquels sont peut-être eux-mêmes sujets à expansion concomitante. En bref : la logique de la concurrence capitaliste des entreprises visant l'expansion dans une même aire économique a été injectée dans l'espace du Conteneur APFS - ce qui montre que la logique n'est pas indemne des données de l'expérience dans ses paradigmes.

En résumé : le Volume APFS macOS co-existe avec au moins 3 autres Volumes APFS (non montés > donc graphiquement invisibles) dans l'espace logique d'un même Conteneur APFS.

 

[SpleenXXX]

Bonjour,

Merci pour cette réponse extrêmement détaillé ! J'avais déjà lu vos précédents commentaires que j'ai trouvé absolument génial d'ailleurs. Merci de nous faire partager vos connaissances !
Cela dit, si je posais la question c'était justement car ça ne coïncide pas en terme d'espace... regardez mieux le screenshot s'il vous plaît.

 

[Membre supprimé 1060554]

ça ne coïncide pas en terme d'espace...

En effet ! Tu fais bien d'attirer pour attention sur ce point. En rédigeant mon message, j'étais concentré sur l'explication "théorique" (ou générale) du dispositif de stockage APFS > au point d'avoir négligé une anomalie dans tes informations de stockage.

Dans mon message précédent > j'avais reconstruit en mode texte le tableau retourné chez toi par diskutil. Le Conteneur APFS fait 385,7 Go > il contient 4 volumes --> 215,1 Go + 41,9 Mo + 1 Go + 2,1 Go = 218, 3 Go (en gros). Espace disponible dans le Conteneur = 167,4 Go.

Or d'après l'«Utilitaire de Disque» > les autres volumes (les 3 autres Volumes APFS, donc) au lieu de ne faire que 3,1 Go > feraient 125,1 Go - soit un décalage de 122 Go. Au lieu qu'il y ait 167,4 Go disponibles > il n'y en aurait que 42,6 Go.

Cette incohérence me surprend d'autant plus que l'«Utilitaire de Disque» est un logiciel graphique (en gros : presse bouton) qui commande en coulisses... principalement l'exécutable diskutil. Comment diskutil commandé en mode graphique peut-il retourner des informations incompatibles avec... diskutil en ligne de commande ?

Je te propose de passer dans le «Terminal» les 2 commandes :

diskutil ap list
df -H /

(mets bien le H en majuscule)

• la 1ère va retourner le tableau détaillé du Conteneur APFS

• la 2è > pour le volume démarré macOS la mesure des espaces : total > occupé > libre [dans un contexte APFS --> total = taille du Conteneur qui mesure la possibilité d'expansion totale du volume macOS > occupé = taille des données du seul volume-cible macOS > libre = espace disponible dans le Conteneur global après soustraction de l'espace occupé par les données additionnées des 4 volumes membres du Conteneur].

Tu n'as qu'à poster ces tableaux ici en copier-coller > mais attention ! étant donné la prolixité du tableau APFS > avant de faire ton coller > 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é).

=> l'exécutable df (display_free_space : afficher l'espace libre) est un véritable juge de paix de l'espace disponible. On va bien voir.

 

[SpleenXXX]

En effet ! Tu fais bien d'attirer pour attention sur ce point. En rédigeant mon message, j'étais concentré sur l'explication "théorique" (ou générale) du dispositif de stockage APFS > au point d'avoir négligé une anomalie dans tes informations de stockage.

Dans mon message précédent > j'avais reconstruit en mode texte le tableau retourné chez toi par diskutil. Le Conteneur APFS fait 385,7 Go > il contient 4 volumes --> 215,1 Go + 41,9 Mo + 1 Go + 2,1 Go = 218, 3 Go (en gros). Espace disponible dans le Conteneur = 167,4 Go.

Or d'après l'«Utilitaire de Disque» > les autres volumes (les 3 autres Volumes APFS, donc) au lieu de ne faire que 3,1 Go > feraient 125,1 Go - soit un décalage de 122 Go. Au lieu qu'il y ait 167,4 Go disponibles > il n'y en aurait que 42,6 Go.

Cette incohérence me surprend d'autant plus que l'«Utilitaire de Disque» est un logiciel graphique (en gros : presse bouton) qui commande en coulisses... principalement l'exécutable diskutil. Comment diskutil commandé en mode graphique peut-il retourner des informations incompatibles avec... diskutil en ligne de commande ?

Je te propose de passer dans le «Terminal» les 2 commandes :

diskutil ap list
df -H /

(mets bien le H en majuscule)

• la 1ère va retourner le tableau détaillé du Conteneur APFS

• la 2è > pour le volume démarré macOS la mesure des espaces : total > occupé > libre [dans un contexte APFS --> total = taille du Conteneur qui mesure la possibilité d'expansion totale du volume macOS > occupé = taille des données du seul volume-cible macOS > libre = espace disponible dans le Conteneur global après soustraction de l'espace occupé par les données additionnées des 4 volumes membres du Conteneur].

Tu n'as qu'à poster ces tableaux ici en copier-coller > mais attention ! étant donné la prolixité du tableau APFS > avant de faire ton coller > 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é).

=> l'exécutable df (display_free_space : afficher l'espace libre) est un véritable juge de paix de l'espace disponible. On va bien voir.

Honnêtement je suis fan de tes messages. C'est vraiment impressionnant le temps que tu dois passer dans ta journée pour les autres.
Pour "diskutil ap list" :



Pour df -H :



Et encore une fois via Utilitaire :



Ne t'en fais pas j'ai l'habitude des forums & je suis développeur

Mais encore une fois, les 126 Go ne sont affichés nul part... c'est à rien n'y comprendre...

Note de la modération : modification des images faite

 

[SpleenXXX]

De retour !
Alors vu la taille je me suis demandé si : c'était une trace de Sierra qu'il avait mis de coté (un peu comme /Previous System sous macOS ou Windows.old sous Windows) OU si c'était des sauvegardes locales TimeMachine (qui m'avait déjà bien pris la tête avant).
Si j'en crois https://eclecticlight.co/2017/06/22/mobile-time-machine-and-its-transformation-in-high-sierra/ ça pourrait être ça.
Comme il s'avère qu'APFS est un système encore jeune, on trouve encore peu d'information dessus. Mais j'aimerai avoir confirmation.
Malheureusement, la commande

sudo tmutil disablelocal

ne fonctionne pas.

 

[Membre supprimé 1060554]

La capture que tu as postée du Container APFS (commande diskutil ap list) montre ce qui suit :

- a) en synthèse :

  Capacity Ceiling (Size):      385,7 Go
  Capacity In Use By Volumes:   308,1 Go (79.9% used)
  Capacity Available:           77,5 Go (20.1% free)

--> la capacité totale du Conteneur APFS (fixée elle-même par celle de son magasin de stockage physique Physical Store > fixée elle-même par la taille de la partition disk0s2 du disque) = 385,7 Go.

Les Volumes APFS recelés dans ce Conteneur consomment 308,1 Go de cette capacité > de sorte qu'il ne reste que 77,5 Go d'espace disponible. Arithmétiquement correct.

----------

La taille d'un Volume APFS (comme celle d'une image-disque de type SPARSE) se cale sur les données actuelles contenues dans ce volume. Si un Volume APFS contient 23 Go de données écrites > sa taille actuelle est de 23 Go. Si la taille des données monte à 48 Go > la taille actualisée du Volume APFS est de 48 Go.

Forts de ce principe > on peut faire l'inventaire analytique des Volumes APFS recelés dans le Conteneur > pour mesurer leur taille actuelle indexée sur celle des données qu'il contiennent.

----------

- b) en analyse :

APFS Volume Disk (Role):   disk1s1 (No specific role)
Name:                      macOS (Case-insensitive)
Capacity Consumed:         181,3 Go
---------------------------------------------------
APFS Volume Disk (Role):   disk1s2 (Preboot)
Name:                      Preboot (Case-insensitive)
Capacity Consumed:         41,9 Mo
---------------------------------------------------
APFS Volume Disk (Role):   disk1s3 (Recovery)
Name:                      Recovery (Case-insensitive)
Capacity Consumed:         1.0 Go
---------------------------------------------------
APFS Volume Disk (Role):   disk1s4 (VM)
Name:                      VM (Case-insensitive)     
Capacity Consumed:         2,1 Go

J'ai élagué le tableau. Il est aisé de faire la somme arithmétique des tailles actuelles (indexées sur leurs données) des 4 Volumes APFS --> 181,3 Go + 41,9 Mo + 1 Go + 2,1 Go = 184,8 Go.

L'espace consommé par les 4 Volumes APFS au prorata de la taille de leurs données est donc de 184,8 Go - en mode analytique. Cet espace consommé est de 308,1 Go en mode synthétique. Soit une augmentation de 123,3 Go qui ne correspondent en apparence à aucune taille actuelle des données d'un volume.

----------

Un option existe > lors de la création d'un Volume APFS > qui est de lui fixer une taille dite de réserve. Cette option fait que le Volume, même vide, occupera au moins dans le Conteneur l'espace correspondant à cette taille de réserve. Par exemple, je peux créer une Volume APFS nommé Brol avec une taille de réserve de 30 Go. Même avec 23 Mo de données contenues > ce volume consommera 30 Go d'espace du Conteneur. Cette taille de réserve ne fixe pas de limite supérieure : je pourrai avoir 50 Go de données dans ce volume, par exemple.

Cette option d'une taille de réserve fixée sur un volume pourrait-elle expliquer les 123,3 Go d'espace-Conteneur occupés sans qu'on puisse les rapporter à des données ? - la réponse est non, car dans ce cas de figure une mention :

Capacity Reserve:          30.0 Go (dans mon exemple)

se trouve attachée à la description du volume et fixe sa taille minimale. Or aucune mention de Capacity Reserve ne se trouve attachée à aucune description des 4 Volume APFS de Spleen.

----------

=> je suis donc contraint à constater un état de fait incohérent --> où le calcul synthétique de la consommation d'espace-Conteneur ne correspond pas aux calculs analytiques de l'espace consommé par chacun des volumes.

=> je ne peux qu'invoquer une erreur logique grave (sans me l'expliquer).

----------

Je t'invite, spleen, à passer une commande de vérification :

diskutil verifyVolume disk1s1

(il va y avoir un gel provisoire du volume pendant cette vérification)

et à poster ici le retour (tu peux faire un copier-coller entre des balises de [code][/code] pour afficher dans une fenêtre de Code. C'est histoire de voir si une erreur est détectée dans le système de fichiers.

 

[SpleenXXX]

diskutil verifyVolume disk1s1

Started file system verification on disk1s1 macOS
Verifying file system
Volume could not be unmounted
Using live mode
Performing fsck_apfs -n -l -x /dev/rdisk1s1
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
error: snap_metadata_val object (oid 0x832c74): invalid extentref_tree_oid (0x0)
Snapshot metadata tree is invalid
The volume /dev/rdisk1s1 could not be verified completely
File system check exit code is 0
Restoring the original state found as mounted
Finished file system verification on disk1s1 macOS

Effectivement, il y a un problème visiblement.

Je sais pas si vous avez vu mon message précédent comme nous avons posté en même temps. Mais j'ai supprimé les snapshots locaux (via tmutil deleteLocalSnapshots) et ça n'a rien changé.

Je vous conseille la lecture de https://cl.ly/moQW très intéressant !

 

[Zorglub38]

Bonjour Spleen

Tu as un disque interne de 500 Go qui est tri-partitionné : partition n°1 (disk0s1) = EFI de 209 Mo (petite partition inaugurale créée par défaut avec une table de partition GUID) > partition n°2 (disk0s2) = macOS de 385 Go (partition de High Sierra) > partition n°3 (disk0s3) = Windows de 114 Go (partition de W-10).

La partition disk0s2 de 385 Go a été convertie par l'APFS au statut de Physical Store = magasin de stockage physique. Ce magasin de stockage de la partition sert de fondation physique (de backup de données) à un Conteneur APFS. Ce Conteneur est comme une espèce de "boîte" logique (un ensemble) comportant 4 objets qui sont des Volumes APFS -->

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +385.7 GB   disk1
                                 Physical Store disk0s2
   1:                APFS Volume macOS                   215.1 GB   disk1s1
   2:                APFS Volume Preboot                 41.9 MB    disk1s2
   3:                APFS Volume Recovery                1.0 GB     disk1s3
   4:                APFS Volume VM                      2.1 GB     disk1s4

Cette distribution de 4 Volumes APFS dans la "boîte logique" du Conteneur APFS est la distribution par défaut --> macOS = le volume de High Sierra > Preboot = le volume de pré-démarrage de macOS --> Recovery = le volume du Système de secours --> VM (Virtual Memory) = le volume qui recèle la sleepimage (fichier où se sauvegardent les contenus de la RAM avant mise-en-sommeil du Système).

Étant donné ce contexte que je viens de brosser > quand tu demandes :



le terme "Autres Volumes" désigne les 3 autres Volumes APFS contenus dans la même "boîte" logique du Conteneur APFS que le volume macOS. En somme : les volumes comparses, que tu ne vois pas parce qu'ils ne sont pas montés par défaut après que tu sois démarré sur macOS.

Si tu créais un nouveau Volume APFS (un 5è) dans le Conteneur APFS (ce qui est entièrement possible) --> alors ce nouveau volume serait lui monté visiblement en même temps que macOS et pourrait servir à stocker des données ou à installer un 2è OS High Sierra (ou à receler un clone de macOS éventuellement).

Intrinsèquement > le système de stockage APFS fait qu'aucun volume n'a une taille prédéfinie (à moins qu'à sa création on n'ait opté pour une taille de réserve déterminée - ce qui n'est pas le cas par défaut), mais n'a que la taille actuelle de ses données. Sa taille maximale est assignée par la taille du Conteneur APFS qui comprend ce volume > taille du Conteneur APFS elle-même déterminée par le Physical Store (magasin de stockage physique) inscrit sur la partition disk0s2 du disque.

L'expansion d'un volume macOS de sa taille actuelle en données vers la limite assignée par la taille du Conteneur APFS global > est "concurrencée" à l'intérieur du Conteneur APFS par l'existence des autres Volumes APFS - lesquels sont peut-être eux-mêmes sujets à expansion concomitante. En bref : la logique de la concurrence capitaliste des entreprises visant l'expansion dans une même aire économique a été injectée dans l'espace du Conteneur APFS - ce qui montre que la logique n'est pas indemne des données de l'expérience dans ses paradigmes.

En résumé : le Volume APFS macOS co-existe avec au moins 3 autres Volumes APFS (non montés > donc graphiquement invisibles) dans l'espace logique d'un même Conteneur APFS.

Parfait comme toujours mais une question comment fait on pour faire apparaitre la partition Recovery 10.13 lorsque l'on presse ALT au démarrage ? Pour ma part pour accédezr à la partition il faut que je presse COMMAND+R.

 

[Membre supprimé 1060554]

Zorglub

J'ai l'impression que le volume Recovery, désormais membre du Conteneur APFS, n'est plus affiché par le gestionnaire de démarrage (appelé par la touche "alt"). Il faut passer par ⌘R.

Ce non affichage à l'écran du gestionnaire de démarrage était déjà le cas > dès lors qu'un système de stockage CoreStorage était inscrit sur la partition de l'OS : dans ce cas-là > j'avais réussi à comprendre la raison de cette exclusion.

Je ne la saisis par dans le cas de l'APFS - une instruction a peut-être été implémentée dans le programme du boot_manager pour que, même s'il détecte le volume Recovery comme démarrable, il ne l'affiche pas à son écran de choix. Je viens de faire, en effet, le test : monter le volume Recovery > effectuer une commande bless pour que l'en-tête du volume l'affiche comme démarrable --> en re-démarrant la touche "alt" pressée > toujours aucun volume affiché.

 

[Locke]

C'est aussi ce que j'ai constaté, il faut bien maintenir cmd+R au redémarrage pour avoir accès à la partition de récupération.

 

[Membre supprimé 1060554]

spleen

Il n'y a rien de tel que les « problèmes » bien retors pour donner un sentiment d'aventure (intellectuelle). Parce que, quand tout marche, on se repose dans la routine du succès. Un petit paradoxe qui n'avait pas échappé aux philosophes : de Rousseau jugeant que le bonheur rend bête à Hegel déclarant que : « les peuples heureux n'ont pas d'histoire » - parce que leur quotidien ressemble à la succession de pages blanches des dimanches de la vie.


La mesure globale de l'espace consommé par des volumes dans ton Conteneur APFS est en contradiction avec l'addition arithmétique de la taille de chacun. J'ai l'impression que ça ne peut signifier qu'une erreur.

Tu as fourni successivement 2 clichés des mesures d'espace dans l'«Utilitaire de Disque» -->

• 1er : macOS = 216 Go > Autres volumes = 125 Go > Disponible = 42 Go

• 2è- : macOS = 181 Go > Autres volumes = 126 Go > Disponible = 77 Go

Tu as donc réussi à alléger ton volume macOS de 35 Go > et ce gain de 35 Go d'espace s'est fidèlement reporté sur l'espace Disponible qui a grimpé de 42 Go à 77 Go = + 35 Go exactement. Alors que l'espace consommé par les « Autres volumes» demeure constant = 125 Go.

Voici ce qui pourrait s'en tirer (conjecturalement) comme conséquence :

il semble que 125 Go d'espace soit pris en bytes du Physical Store, qui est le magasin de stockage physique du Conteneur. Ces 125 Go d'espace ne relèvent d'aucun des 4 Volumes APFS actuels. Il s'agirait donc de bytes du Physical Store marqués par des flags "non-libres" > sans que ces bytes ne correspondent à aucun des Volumes APFS actuels. Comme s'ils avaient été marqués par erreur "non-libres" en-dehors de toute allocation à des Volumes. Ils seraient comptabilisés, en mesure synthétisée, comme correspondant à une occupation d'espace par un volume > puisque seules les écritures sur des bytes compris dans un volume sont considérées comme correspondant à des données, ce qui rend ces bytes : non-libres. Mais les bytes en question sont hors périmètre actuel d'un volume : ce seraient donc des bytes hors-volume (donc en principe "disponibles") marqués par erreur par des flags "non-libres" (comme s'ils portaient des écritures de données relevant d'un volume).


[Je ne sais pas si cette erreur manifeste dans l'assignation des bytes > a un rapport avec l'erreur dans un des fichiers de ton système de fichiers APFS :

Checking the snapshot metadata tree
error: snap_metadata_val object (oid 0x832c74): invalid extentref_tree_oid (0x0)
Snapshot metadata tree is invalid
The volume /dev/rdisk1s1 could not be verified completely

car ledit « arbre des métadonnées de snapshots » n'a pas pour moi un sens clair.]

----------

Au cas où tu aurais une sauvegarde démarrable des données du volume macOS > tu pourrais tenter une expérimentation hardie mettant à l'épreuve expérimentale ma conjecture d'une erreur de flags sur les bytes du Physical Store -->

si j'indroduis une conjecture seconde : que les flags "non-libres" actuellement attachés à des bytes hors volumes du Physical Store seraient "volatiles" (càd. susceptibles d'être effacés) > dans la mesure où ils ne relèvent pas du périmètre d'un volume les faisant correspondre à des données de fichiers (bref : ils auraient le statut philosophique de l'« accident » logique et pas de l'« attribut » logique) --> alors il s'ensuit que :

• la création dans le Conteneur APFS d'un nouveau volume (un 5è) > avec une taille de réserve fixe lui faisant revendiquer directement un espace donné des bytes du Physical Store > taille de réserve telle qu'elle excèderait la mesure de l'espace reconnu Disponible pour empiéter sur l'espace attribué par erreur aux Autres volumes --> pourrait forcer la volatilisation des flags "non-libres" accidentellement attribués à des bytes hors volumes et n'ayant pas le caractère de l'attribution à de vrais fichiers dans le périmètre d'un volume.

Tu admettras sans mal que cette procédure expérimentale est le fruit d'un raisonnement plutôt alambiqué. Donc il serait envisageable dans le «Terminal» de commander la création d'un 5è volume du genre :

diskutil ap addVolume disk1 apfs Purge -reserve 100g

• cherchant à créer un nouveau volume nommé Purge avec une taille de réserve de 100 Go prenant d'emblée cet espace sur les bytes du Physical Store > càd. excédant l'espace considéré comme Disponible de 23 Go et empiétant sur l'espace considéré par erreur attribué à d'Autres volumes de 23 Go également.

=> si la commande passait et si un volume de 100 Go d'emprise sur les bytes arrivait d'entrée à être créé > alors forcément l'espace pris par les Autres volumes serait bien obligé de varier en conséquence par volatilisation des flags "non-libres" accidentellement attachés.

 

[Madalvée]

Je me greffe. Mon mac ne supprime plus aucun espace : j'ai beau supprimer 50 Go mon espace libre ne bouge pas, corbeille vidé, SOS utilitaire disque passé OK.
Le clone affiche le vrai espace.

 

[Membre supprimé 1060554]

Madalvée

Est-ce que tu peux aller à : Menu  > À propos de ce Mac > Stockage > prendre une capture du panneau montrant la barre de distribution de l'espace dans le volume > et la poster ici ?

 

[Madalvée]

Je ne vais pas polluer le fil plus longtemps : j'ai vu sur un vieux fil que Time machine stocke des fichiers temporaires sur le disque et que sa première sauvegarde n'est pas terminée, je reviendrai si le problème n'est pas résolu à l'issue de la sauvegarde.

 

[SpleenXXX]

spleen

Il n'y a rien de tel que les « problèmes » bien retors pour donner un sentiment d'aventure (intellectuelle). Parce que, quand tout marche, on se repose dans la routine du succès. Un petit paradoxe qui n'avait pas échappé aux philosophes : de Rousseau jugeant que le bonheur rend bête à Hegel déclarant que : « les peuples heureux n'ont pas d'histoire » - parce que leur quotidien ressemble à la succession de pages blanches des dimanches de la vie.


La mesure globale de l'espace consommé par des volumes dans ton Conteneur APFS est en contradiction avec l'addition arithmétique de la taille de chacun. J'ai l'impression que ça ne peut signifier qu'une erreur.

Tu as fourni successivement 2 clichés des mesures d'espace dans l'«Utilitaire de Disque» -->

• 1er : macOS = 216 Go > Autres volumes = 125 Go > Disponible = 42 Go

• 2è- : macOS = 181 Go > Autres volumes = 126 Go > Disponible = 77 Go

Tu as donc réussi à alléger ton volume macOS de 35 Go > et ce gain de 35 Go d'espace s'est fidèlement reporté sur l'espace Disponible qui a grimpé de 42 Go à 77 Go = + 35 Go exactement. Alors que l'espace consommé par les « Autres volumes» demeure constant = 125 Go.

Voici ce qui pourrait s'en tirer (conjecturalement) comme conséquence :

il semble que 125 Go d'espace soit pris en bytes du Physical Store, qui est le magasin de stockage physique du Conteneur. Ces 125 Go d'espace ne relèvent d'aucun des 4 Volumes APFS actuels. Il s'agirait donc de bytes du Physical Store marqués par des flags "non-libres" > sans que ces bytes ne correspondent à aucun des Volumes APFS actuels. Comme s'ils avaient été marqués par erreur "non-libres" en-dehors de toute allocation à des Volumes. Ils seraient comptabilisés, en mesure synthétisée, comme correspondant à une occupation d'espace par un volume > puisque seules les écritures sur des bytes compris dans un volume sont considérées comme correspondant à des données, ce qui rend ces bytes : non-libres. Mais les bytes en question sont hors périmètre actuel d'un volume : ce seraient donc des bytes hors-volume (donc en principe "disponibles") marqués par erreur par des flags "non-libres" (comme s'ils portaient des écritures de données relevant d'un volume).


[Je ne sais pas si cette erreur manifeste dans l'assignation des bytes > a un rapport avec l'erreur dans un des fichiers de ton système de fichiers APFS :

Checking the snapshot metadata tree
error: snap_metadata_val object (oid 0x832c74): invalid extentref_tree_oid (0x0)
Snapshot metadata tree is invalid
The volume /dev/rdisk1s1 could not be verified completely

car ledit « arbre des métadonnées de snapshots » n'a pas pour moi un sens clair.]

----------

Au cas où tu aurais une sauvegarde démarrable des données du volume macOS > tu pourrais tenter une expérimentation hardie mettant à l'épreuve expérimentale ma conjecture d'une erreur de flags sur les bytes du Physical Store -->

si j'indroduis une conjecture seconde : que les flags "non-libres" actuellement attachés à des bytes hors volumes du Physical Store seraient "volatiles" (càd. susceptibles d'être effacés) > dans la mesure où ils ne relèvent pas du périmètre d'un volume les faisant correspondre à des données de fichiers (bref : ils auraient le statut philosophique de l'« accident » logique et pas de l'« attribut » logique) --> alors il s'ensuit que :

• la création dans le Conteneur APFS d'un nouveau volume (un 5è) > avec une taille de réserve fixe lui faisant revendiquer directement un espace donné des bytes du Physical Store > taille de réserve telle qu'elle excèderait la mesure de l'espace reconnu Disponible pour empiéter sur l'espace attribué par erreur aux Autres volumes --> pourrait forcer la volatilisation des flags "non-libres" accidentellement attribués à des bytes hors volumes et n'ayant pas le caractère de l'attribution à de vrais fichiers dans le périmètre d'un volume.

Tu admettras sans mal que cette procédure expérimentale est le fruit d'un raisonnement plutôt alambiqué. Donc il serait envisageable dans le «Terminal» de commander la création d'un 5è volume du genre :

diskutil ap addVolume disk1 apfs Purge -reserve 100g

• cherchant à créer un nouveau volume nommé Purge avec une taille de réserve de 100 Go prenant d'emblée cet espace sur les bytes du Physical Store > càd. excédant l'espace considéré comme Disponible de 23 Go et empiétant sur l'espace considéré par erreur attribué à d'Autres volumes de 23 Go également.

=> si la commande passait et si un volume de 100 Go d'emprise sur les bytes arrivait d'entrée à être créé > alors forcément l'espace pris par les Autres volumes serait bien obligé de varier en conséquence par volatilisation des flags "non-libres" accidentellement attachés.

C'est ce que j'ai déjà essayé via l'Utilitaire de disques. Cela donne des choses encore plus étranges de mon point de vue. 100go comme taille de réserve je ne peux pas :

sudo diskutil ap addVolume disk1 apfs Purge -reserve 100g
Exporting new unencrypted APFS Volume "Purge" from APFS Container Reference disk1 with a 100000000000-byte reserve
Started APFS operation on disk1
Preparing to add APFS Volume to APFS Container disk1
Error: -69605: There is not enough free space in the APFS Container for this operation

Mais avec 80 go de taille de réserve, cela passe mais c'est vraiment étrange : https://cl.ly/moUN https://cl.ly/mp6z
Une fois supprimé, retour comme avant...

Dans le doute, j'ai revérifié le volume : https://cl.ly/moOo cette fois c'est un problème qui semble corrigé.

P.S : je te suis dans tes divagations de début de commentaire


@Madalvée : attention la gestion des snapshots locaux change un peu avec High Sierra. Je te conseille la lecture de cet article : https://cl.ly/mnvS

 

[Membre supprimé 1060554]

@ Madalvée

C'était juste pour savoir si l'onglet Stockage t'affichait un grande quantité d'espace purgeable ou non ?

 

[SpleenXXX]

Pardon, j'ai fait une vérification de la partition s1 plutôt que du disque entier :



Du coup, j'ai maintenant une autre erreur. Avancée, stagnation ou régression ?

Note de la modération : modification image faite