Ce forum est en partie financé par l’affichage de publicités. Merci de désactiver votre bloqueur de publicités pour nous permettre de continuer à fournir ce service.

10.13 High Sierra APFS : en savoir plus

Discussion dans 'macOS' créé par da capo, 28 Septembre 2017.

Modérateurs: Aliboron, bompi, daffyb
  1. da capo

    da capo abonné absent
    Club MacG

    Inscrit:
    12 Août 2001
    Messages:
    17 364
    J'aime reçus:
    3 559
    Cool.


    En effet, en insérant apfs (en après un tab pour suggérer la suite) dans un terminal, seule la commande apfs_hfs_convert est proposée.

    C'était aussi l'objet de ma question un peu plus haut (mon post cité)
     
  2. killerraoul

    killerraoul Membre junior

    Inscrit:
    16 Novembre 2016
    Messages:
    35
    J'aime reçus:
    4
    Franchement merci pour vos informations. Très très intéressant de comprendre comment fonctionne ce système de fichier. Et vos différents retours.

    Donc un grand merci (pour ma culture). Vous avez guéri ma paranoïa « perte de Go ». ^^
     
  3. macomaniac

    macomaniac Ouroboros
    Club MacG

    Inscrit:
    20 Septembre 2012
    Messages:
    57 383
    J'aime reçus:
    19 222
    Je reviens dans ce fil pour rendre compte d'une expérimentation.

    Dans un panneau du logiciel «CronniX» dédié au Cron pour l'utilisateur (et pas pour le Système) --> j'ai défini une tâche horaire consistant dans l'exécution de la commande :
    Code (Text):
    tmutil localsnapshot
    • Pourquoi cette commande directe va-t-elle marcher > alors que tmutil doit être exécuté par l'utilisateur root (et pas par un admin macomaniac) pour tout ce qui est opératoire et pas informatif ? - parce que, pour éviter les complications liées à l'emploi de sudo - ce qui demande de renseigner un mot-de-passe - j'ai opté pour le procédé dit du setuid_bit via la commande préalable :
      Code (Text):
      sudo chmod 4755 /usr/bin/tmutil

    • le setuid_bit (set_root_user_id_bit) consiste à substituer sur un utilitaire au bit d'exécution standard de l'user (x) le bit exécutif de root_substitué (s) --> ce qui fait que tout déclenchement d'exécution par un utilisateur standard se trouve converti automatiquement en exécution de l'utilitaire sous l'identité de root. Le procédé du setuid_bit économise donc l'emploi de sudo

    Donc la commande à exécuter dans le panneau Cron pour l'utilisateur de «CronniX» :
    Code (Text):
    tmutil localsnapshot
    passe sans aucune difficulté grâce au setuid_bit exécutif d'utilisateur fixé sur l'utilitaire qui injecte l'identité de root à l'exécution.

    Afin de pouvoir vérifier où j'en suis de l'accumulation des snapshots > je me suis fabriqué une petite application avec l'«Éditeur de Script» qui consiste en la commande suivante :
    Code (Text):
    do shell script "tmutil listlocalsnapshots / | open -f"
    • il s'agit de l'ordre classique : exécuter le script shell suivant mis entre "" --> le contenu en question consistant dans la commande :
      Code (Text):
      tmutil listlocalsnapshots / | open -f

    • l'utilitaire tmutil toujours est appelé avec le verbe listlocalsnapshots (lister les snapshots locaux) > le pipe | redirigeant le flux de sortie de cette commande sur l'utilitaire open (ouvrir) accompagné de l'option -f qui signifie : "lire le flux passé en entrée à l'utilitaire et l'ouvrir dans l'éditeur de texte par défaut - càd. «TextEdit»".

    un clic sur le raccourci de cette application loggé dans le Dock affiche directement la liste des snapshots locaux existants dans une fenêtre de «TextEdit». Cette commande me permet de vérifier que le cron horaire est parfaitement fonctionnel et qu'un shapshot se trouve affiché par heure écoulée.

    Ce petit bricolage : prise de snapshots automatisée > outil d'affichage de la liste fonctionne donc bien.

    ----------

    Pourquoi est-ce que je me suis lancé dans cette opération ? - c'est que plusieurs expérimentations que j'ai effectuées montrent que la technologie du snapshot apfs fonctionne fantastiquement bien. Exemple : j'arrose mon Bureau de session d'une vingtaine de documents variés > et manuellement pour l'expérience je crée ensuite un snapshot dont je vérifie qu'il est bien affiché dans la liste. Comme j'ai horreur des Bureaux non-vides > je mets à la corbeille tout le bazar et je la vide.

    Je re-démarre par ⌘R en mode Recovery locale > option : Récupérer une sauvegarde Time Machine (NB. TM est désactivé chez moi et je n'ai aucun volume de DDE dédié à une sauvegarde TM) --> le logiciel m'affiche le volume de mon OS comme disque de snapshots locaux > je le choisis > et je revois s'afficher la liste de mes shapshots. Je sélectionne le dernier (effectué avant mise à la corbeille des fichiers du Bureau) et je presse le bouton de récupération. En une seconde environ l'opération s'effectue et un re-démarrage automatique s'opère sur l'OS --> à l'ouverture de ma session > tous les fichiers précédemment supprimés sont affichés sur le Bureau. Rien n'a donc été perdu.

    ----------

    La question qui se pose alors est la suivante : est-ce que l'accumulation des snapshots au rythme de un par heure ne va pas faire pression sur l'occupation du volume ?

    Je me suis livré à quelques vérifications > dont il me paraît ressortir ceci -->

    • si je passe une commande :
      Code (Text):
      df -H /
      régulière (et en supposant que je n'ajoute pas de fichiers ni n'en supprime dans le volume de l'OS démarré) --> la taille des blocs occupés correspondant au volume reste constante. Dans mon expérience > j'obtiens une valeur de l'ordre de 60 Go.

    si je passe une commande :
    Code (Text):
    sudo du -shx /
    régulière (toujours à conditions constante de gestion des écritures de fichiers dans le volume de l'OS) --> la taille mesurée des fichiers du volume augmente progressivement. Progressivement mais non dramatiquement : j'ai eu l'impression (dans ma configuration du moins) que la taille d'un snapshot individuel était de l'ordre de 200 Mo environ (quand même ! - ce n'est pas rien...). Donc 24 heures de snapshots automatiques va donner aux environs de 5 Go > ce qui fait que je vais obtenir une mesure de taille de fichiers de 65 Go environ.

    Mais où sont lesdits snapshots ? - mon enquête précédente m'a montré qu'il ne sont nulle part dans le périmétre du volume monté sous forme de fichiers identifiables (comme les anciens snapshots locaux de Time Machine). Ils relèvent d'une branche de l'arbre du système de fichiers apfs intitulée : « arbre de métadonnées de snapshots ». Ce qui est excessivement curieux est le point suivant : l'accumulation des snapshots ne fait pas varier l'espace de blocs occupés par des écritures du volume (60 Go constants) mais fait augmenter la mesure de la taille des fichiers du volume (65 Go).

    J'ai donc un volume recelant 65 Go en mesure de fichiers alors que les blocs écrits sont évalués à 60 Go. Il faut alors admettre que les 5 Go de fichiers excédentaires relèvent du système de fichiers (inscrit sur l'en-tête de la partition) - système de fichiers capable d'inflation logique en taille de métadonnées. Cette inflation en taille du système de fichiers se trouve portée au compte de la quantité de fichiers du volume (ce qui équivaut à une "pression" exercée sur le volume) > sans que cela ne correspondent à la mesure des blocs portant les écritures spécifiques du volume.

    Il y a là-dedans quelque chose d'assez trouble - que, je l'avoue, je n'ai pas tiré bien au clair pour l'instant. Qui semble avoir pour effet un trouble dans la représentation de la taille exacte d'un Volume APFS.

    ----------

    Comment faire (pratiquement) pour ne pas me laisser déborder par l'accumulation horaire des snapshots ? Je me suis créé une seconde petite application avec l'«Éditeur de Script» dont voici la commande interne :
    Code (Text):
    do shell script "tmutil thinlocalsnapshots / 1000000000 1"
    Comme on nage, avec le man actuel de tmutil, dans la confusion la plus fantastique entre options classiques de Time Machine et options nouvelles de snapshots apfs, il m'a fallu un peu tâtonner pour distinguer les chiens des chats et voici le sens de la commande :

    • le verbe thinlocalsnapshots (amincir les snapshots locaux) est utilisé > avec le point de montage / du volume-Système démarré > une première valeur 1000000000 qui correspond au "montant de la purge à effectuer" (purge amount) calculé en quantité de bytes à purger (1000000000 = 1 Go) > et une seconde valeur 1 qui correspond au degré de l'urgence (urgency : graduable de 1 à 4) à effectuer la purge des bytes

    • il faut une large minute pour que la commande prioritaire de purger 1 Go de bytes s'effectue après quoi, si j'active ma petite application listant les snapshots locaux, je m'aperçois qu'un certain nombre ont disparu (environ 5 à 200 Mo chaque). À force de répéter l'action de mon application > j'arrive à ne garder qu'un seul snapshot. Parvenu à ce plancher de purge > je retrouve une congruence entre la mesure de l'occupation des blocs et celle de la taille des fichiers.

    ----------


    Comme les aimables lecteurs de cette prose de fin de semaine l'aperçoivent --> une fantastique confusion règne actuellement sur la question des snapshots locaux apfs (le man de tmutil étant en-dessous de tout sur la question). Vu les enjeux cruciaux de cette technologie (qui permet en un clin d'œil de restaurer l'état d'un volume en le ramenant au contexte de l'instant T correspondant à un snapshot) --> je m'étonne qu'aucune application graphique ne soit fournie avec l'OS High Sierra afin de gérer ces ressources (en intégrant : prise automatique de snapshots > rythme de la prise > lecture de la "pression" sur le volume en terme de taille de fichiers > procédé de purge des anciens snapshots).

    Parce que, même s'il s'agit comme pour Time Machine de pouvoir récupérer un état temporel du volume > la technologie mise en œuvre n'a rien à voir et le panneau actuel du logiciel TM ne permet aucunement de gérer cette technologie. À se demander si ce ne seront pas des développeurs qui viendront proposer des applications de tierce partie pour gérer les snapshots apfs (un comble, quand même).
     
    #23 macomaniac, 11 Novembre 2017
    Dernière édition: 11 Novembre 2017
  4. bompi

    bompi El Moderador
    Modérateur Club MacG

    Inscrit:
    12 Février 2004
    Messages:
    41 816
    J'aime reçus:
    3 121
    Je ne suis pas aussi étonné que toi de la désinvolture d'Apple sur ce sujet : on peut se remémorer la découverte du nouvel Utilitaire de Disques venu avec Sierra, où un certain nombre de fonctions bien utiles avaient disparu [et s'en sont suivies chez certains des acrobaties périlleuses pour installer la version précédente... ;)]
    C'est dans la foulée de la "simplification" qui amène à rendre les différentes bibliothèques invisibles dans le Finder, par défaut.

    Par ailleurs, on voit bien à leurs atermoiements que les techniciens d'Apple ne sont pas prêts (moins que toi, en tout cas :)) à prendre toute la mesure de ce nouveau système de fichiers.

    En fait, ce qu'Apple aimerait, c'est sans doute que tu n'aies plus le droit d'ouvrir un shell ou une quelconque commande avec sudo et que tu puisses démontrer que ce sont des amateurs sur certains sujets. Avec un macOS aussi fermé que iOS, on ne verrait pas ce côté "version bêta" de l'intégration du système de fichiers.
    Utiliser tmutil de la sorte est peut-être dû à un travail en cours visant à réécrire complètement Time Machine pour s'adapter à APFS, regroupant ainsi les nouvelles fonctionnalités d'APFS et celles de l'ancien Time Machine.

    -----

    Pour le reste, je ne vois pas d'incongruité particulière à tes constatations. Les instantanés sont des métadonnées (une description de l'état des blocks qui contiennent des données) pas des données (pas celles de l'utilisateur, quoi).
    Donc que cela soit stocké dans un espace réservé aux métadonnées, cela fait sens.

    Au passage : en aucun cas l'instantané ne contient les données réelles qui sont enregistrées sur le disque. Sans cela il serait inefficace. C'est une image de l'état du système de fichiers, pas du contenu des fichiers.

    Une fois qu'un instantané a été réalisé, le système maintient la liste des actions qui sont réalisées mais ne les actualise pas. Par exemple :
    • je fais un instantané
    • je supprime ensuite un fichier
    Tant que je n'aurai pas annulé l'instantané, la suppression ne sera pas effectuée. Pour autant, le fichier ne sera plus visible du Finder, de ls etc. Mais les blocks qu'il occupe continueront d'être occupés.
    D'où :
    • si je supprime l'instantané, le fichier est réellement supprimé ;
    • si, au contraire, je retourne à l'instantané, le fichier réapparaît dans le Finder ou avec ls.
    Question : que doivent afficher les commandes du et df ? Ce que le système de fichiers leur indique, c'est-à-dire ce qui correspond à la situation en cours (potentiellement, plus de fichier), qui n'est qu'une vision de la réalité. Cette vision de la réalité devient la réalité si je supprime l'instantané. Ou alors est annulée si j'y retourne.

    Je n'ai pas les moyens de faire de tests mais je dirais donc que le scénario suivant est plausible :
    • je n'ai pas d'instantané
    • (A) le Finder me dit que j'ai un disque de 100 GB avec 40 GB libres
    • je fais un instantané
    • je supprime 5 GB de données
    • (B) le Finder me dit que j'ai un disque de 100 GB avec 45 GB libres
    • si :
      • je retourne à l'instantané : (C) le Finder me dit que j'ai un disque de 100 GB avec 40 GB libres
      • je supprime l'instantané : (D) le Finder me dit que j'ai un disque de 100 GB avec 45 GB libres
    En (A), (C) et (D), Finder et réalité sont dans l'ensemble en phase.
    En (B) le Finder m'indique ce que sera la réalité si je persiste dans la direction choisie, celle de (D) : au bout d'un certain temps, que je ne connais pas, l'instantané pourrait bien être supprimé. Le Finder m'indique donc un potentiel, pas ce qui est actuellement stocké sur le volume physique.

    Le jour où j'ai HS, je vérifierai.
     
    da capo, bibicool16 et macomaniac aiment ça.
  5. gimlioak

    gimlioak Membre junior

    Inscrit:
    28 Septembre 2017
    Messages:
    29
    J'aime reçus:
    0
    Bonjour,

    Je me pose une question.

    Code (Text):
    MacPro:~ jef$ diskutil list
    /dev/disk0 (internal, physical):
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:      GUID_partition_scheme                        *500.1 GB   disk0
       1:                        EFI EFI                     209.7 MB   disk0s1
       2:                 Apple_APFS Container disk5         499.8 GB   disk0s2

    /dev/disk1 (internal, physical):
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:      GUID_partition_scheme                        *500.1 GB   disk1
       1:                        EFI EFI                     209.7 MB   disk1s1
       2:                 Apple_APFS Container disk6         499.8 GB   disk1s2

    /dev/disk2 (internal, physical):
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:      GUID_partition_scheme                        *512.1 GB   disk2
       1:                        EFI EFI                     209.7 MB   disk2s1
       2:                 Apple_APFS Container disk8         511.8 GB   disk2s2

    /dev/disk3 (internal, physical):
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:      GUID_partition_scheme                        *6.0 TB     disk3
       1:                        EFI EFI                     209.7 MB   disk3s1
       2:                  Apple_HFS BigData                 6.0 TB     disk3s2

    /dev/disk4 (internal, physical):
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:      GUID_partition_scheme                        *512.1 GB   disk4
       1:                        EFI EFI                     209.7 MB   disk4s1
       2:                 Apple_APFS Container disk7         511.9 GB   disk4s2

    /dev/disk5 (synthesized):
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:      APFS Container Scheme -                      +499.8 GB   disk5
                                     Physical Store disk0s2
       1:                APFS Volume VMSSD                   125.7 GB   disk5s1

    /dev/disk6 (synthesized):
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:      APFS Container Scheme -                      +499.8 GB   disk6
                                     Physical Store disk1s2
       1:                APFS Volume SSD                     311.8 GB   disk6s1

    /dev/disk7 (synthesized):
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:      APFS Container Scheme -                      +511.9 GB   disk7
                                     Physical Store disk4s2
       1:                APFS Volume MacOS                   303.2 GB   disk7s1
       2:                APFS Volume Preboot                 19.8 MB    disk7s2
       3:                APFS Volume Recovery                520.8 MB   disk7s3
       4:                APFS Volume VM                      2.1 GB     disk7s4

    /dev/disk8 (synthesized):
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:      APFS Container Scheme -                      +511.8 GB   disk8
                                     Physical Store disk2s2
       1:                APFS Volume WinVM                   95.2 GB    disk8s1

    /dev/disk9 (external, physical):
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:      GUID_partition_scheme                        *512.1 GB   disk9
       1:                        EFI EFI                     209.7 MB   disk9s1
       2:                  Apple_HFS Working SSD             511.8 GB   disk9s2

    /dev/disk10 (external, physical):
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:      GUID_partition_scheme                        *500.1 GB   disk10
       1:                        EFI EFI                     209.7 MB   disk10s1
       2:                  Apple_HFS Data                    499.8 GB   disk10s2
    Quelle est la différence entre Physical Store et APFS Container ? Et entre synthesized et "internal, physical"

    De plus les disques 9 et 10 sont vus comme externes alors qu'ils sont sur une carte SATA3 interne au macpro. Ils ont d'ailleurs l'icone de disques externes. Y a-t-il moyen de dire à macOS que ce sont des disques internes ?

    Merci

    EDIT: ha je viens de comprendre que les disques sont là 2 fois. Le disk4 est un espèce de container pour le disk7.

    EDIT2: en relisant le post de macomaniac j'ai mieux compris :) C'est quand même un affichage tarabiscoté :)
     
    #25 gimlioak, 16 Novembre 2017
    Dernière édition: 16 Novembre 2017
  6. macomaniac

    macomaniac Ouroboros
    Club MacG

    Inscrit:
    20 Septembre 2012
    Messages:
    57 383
    J'aime reçus:
    19 222
    Salut gimlioak

    Avec l'apfs > le périmètre d'une partition classique du disque dur (la disk0s2 ou la disk4s2) se trouve converti au statut de : "magasin de stockage physique" des écritures. Un sorte d'émulation de disque dur local (comme un dmg fixé à demeure). C'est le « Physical Store » : la base de données des écritures de l'apfs. Ce socle ou cette base de l'apfs appartient au plan du disque physique : c'est la série des blocs contenus dans le périmètre de la partition > qui ont simplement été redéfinis logiquement comme disque dur émulé.


    En référence à ce magasin de stockage physique (ou à ce disque dur local) du « Physical Store » --> se trouve virtualisée une couche logique secondaire : un Conteneur Logique. C'est une espèce de redondance logique du magasin de stockage physique : la virtualisation d'un disque au second degré. Disque « synthétisé » logiquement comme un plan formel parallèle au plan physique du magasin. Le Conteneur est donc assimilé à un disque de second degré par rapport au disque physique qui recèle le magasin (par exemple disk1 vs disk0).

    Sur le plan de ce disque virtuel montent 4 Volumes : Macintosh HD (Système) > Preboot (pré-démarrage) > Recovery (secours) > VM (mémoire virtuelle image de la RAM). Ces 4 volumes sont identifiés en tant qu'appareils distincts (devices) comme s'il s'agissait de partitions du disque virtuel du Conteneur > donc si le Conteneur est identifié comme disk1 --> Macintosh HD disk1s1 > Preboot disk1s2 > Recovery disk1s3 > VM disk1s4.

    Mais il ne s'agit pas de vraies partitions, qui découperaient a priori sur le plan logique virtuel du Conteneur des tranches logiques fixes allant de tel n° de bloc à tel n° de bloc. Ce sont de pseudo-partitions - une simple convention pour adresser ces volumes.

    C'est qu'on a affaire ici à quelque chose de jamais vu : 4 volumes se partageant le plan d'un disque virtuel sans que ce plan en soit segmenté en partitions. Mais qui dit volume dit système de fichiers local permettant le montage du volume. Il y donc logiquement, de toute nécessité, 4 systèmes de fichiers apfs locaux.

    Pour représenter la chose par « métaphore » : c'est comme si, aux 4 coins d'un carré virtuel constituant le plan logique du disque du Conteneur > était inscrits 4 systèmes de fichiers apfs > chacun générant un volume sur le reste de l'aire du disque. Mais comme chacun de ces systèmes de fichiers a 3 autres concurrents (concomitants) aux 3 autres coins > la génération d'un volume est potentielle et pas actuelle : c'est une option sur l'espace du disque > l'effectivité du volume se réduisant à la taille actuelle de ses fichiers.

    Il y a donc 4 points de montage (dev nodes) de volumes sur le plan logique virtuel du disque du Conteneur. Mais comme les volumes ne correspondent pas à des réelles partitions > ces points de montage ne peuvent pas être traversés pour un accès à une série continue de blocs qui constituerait l'espace-partition sur lequel monterait le volume (comme dans les dispositifs traditionnels).

    Et comme cette pluralité de systèmes de fichiers concomitants ne peut pas être un agrégat > il faut supposer qu'il existe un système de fichiers maître, qui est en somme comme le tronc dont les 4 systèmes de fichiers montant les 4 volumes sont des branches. Ou encore : on a un système de fichiers racine (le fsroot tree) > et ses 4 embranchements (ou dérivations). Bref : il s'agirait avec l'apfs d'un système de fichiers de systèmes de fichiers.

    ----------

    N'étant pas plus que toi (je suppose) informaticien (ni pas éducation, ni par profession) > je suis contraint d'« imaginer nominalement » des « causes » dont je n'ai pas la connaissance suffisante et dont je ne fais que constater les « effets » empiriques. Ignorant donc l'« essence réelle » des choses ("causae cosarum") > je ne fais qu'en exprimer une « essence nominale » (conformément à la distinction du nominaliste John Locke). Ce qui marque les limites de mon discours.
     
    #26 macomaniac, 17 Novembre 2017
    Dernière édition: 17 Novembre 2017
    bibicool16 et oyapoque aiment ça.
  7. gimlioak

    gimlioak Membre junior

    Inscrit:
    28 Septembre 2017
    Messages:
    29
    J'aime reçus:
    0
    Merci pour ces informations comme d’habitude claires et précises.
     
  8. soiziclecros

    soiziclecros Membre émérite

    Inscrit:
    23 Janvier 2011
    Messages:
    766
    J'aime reçus:
    27
    J'avoue ma totale ignorance sur ce nouveau système, mais il me rappelle mon NAS (synology): sur un disque dur de 2 To, il montre 4 partitions (home, homes, photo et video) qui sont vues par le mac, mais chacune indique qu'elle dispose de toute la partie libre du disque ce que j'avais trouvé curieux, elles sont donc mouvantes.
     
  9. gimlioak

    gimlioak Membre junior

    Inscrit:
    28 Septembre 2017
    Messages:
    29
    J'aime reçus:
    0
    Bonjour
    Ce n’est pas tout à fait la même chose. Il s’agit de 4 dossiers partagés sur le même disque.
    Bonne soirée
     
  10. soiziclecros

    soiziclecros Membre émérite

    Inscrit:
    23 Janvier 2011
    Messages:
    766
    J'aime reçus:
    27
    Merci pour cette précision.
     
  11. damienjdc

    damienjdc Nouveau membre

    Inscrit:
    4 Janvier 2009
    Messages:
    8
    J'aime reçus:
    3
    Alors là un très grand merci pour ce cours ! (c'est plus qu'une réponse). Ce sont exactement les explications que je cherchaient. Comme l'auteur de ce post j'ai été assez déconcerté par ces nouveaux concepts APFS.
    Maintenant je vais pouvoir gérer correctement mes partitions.

    Encore Merci ! Cordialement
     
  12. Jacques L

    Jacques L Membre d’élite
    Club MacG

    Inscrit:
    4 Septembre 2004
    Messages:
    1 492
    J'aime reçus:
    59
    J'ai bien peur de passer pour le cancre de la compagnie, j'ai :
    Code (Text):
    MBP-de-Jacques:~ jacques$ diskutil list
    /dev/disk0 (internal, physical):
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:      GUID_partition_scheme                        *251.0 GB   disk0
       1:                        EFI EFI                     209.7 MB   disk0s1
       2:                 Apple_APFS Container disk1         250.8 GB   disk0s2

    /dev/disk1 (synthesized):
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:      APFS Container Scheme -                      +250.8 GB   disk1
                                     Physical Store disk0s2
       1:                APFS Volume Macajac SSD             96.9 GB    disk1s1
       2:                APFS Volume Preboot                 10.3 MB    disk1s2
       3:                APFS Volume Recovery                519.0 MB   disk1s3
       4:                APFS Volume VM                      2.1 GB     disk1s4

    /dev/disk2 (disk image):
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:      GUID_partition_scheme                        +9.3 GB     disk2
       1:                        EFI EFI                     209.7 MB   disk2s1
       2:                  Apple_HFS InstallESD              9.0 GB     disk2s2
     
    En tant que “Mac user“ de base, bêtement comme c'était autrefois, je pensais pouvoir trouver recovery simplement en redémarrant avec alt enfoncé et bien non je ne le trouve pas et pourtant il est dans la liste!

    pas taper, pas taper, je porte des lunettes... :sorry:
     
  13. macomaniac

    macomaniac Ouroboros
    Club MacG

    Inscrit:
    20 Septembre 2012
    Messages:
    57 383
    J'aime reçus:
    19 222
    :coucou: Jacques


    L'OS de secours 10.13 (contenu dans le volume Recovery du Conteneur apfs) ne se lance plus qu'avec les touches ⌘R (cmd R). Le volume Recovery n'est plus affiché à l'écran du gestionnaire de démarrage -->
    • simple convention restrictive de l'ingéniérie  dont je ne connais pas la raison. Si tu installes rEFInd (gestionnaire de démarrage tiers) --> tu as le volume de secours affiché en-dessous de celui de l'OS High Sierra : preuve que le volume Recovery est bien monté et détectable dans le temps du boot du Mac...
     
    Jacques L aime ça.
  14. Jacques L

    Jacques L Membre d’élite
    Club MacG

    Inscrit:
    4 Septembre 2004
    Messages:
    1 492
    J'aime reçus:
    59
    Merci tout plein Macomaniac, tu réponds plus vite que ton ombre :)
     
  15. Bonjour,

    Lorsque Mojave sortira prochainement j’aimerais faire une clean installation sur mon iMac.

    Possédant un Fusion Drive, Mojave supporte l’APFS pour ce type de stockage, lorsque je serais en mode « Recovery » je formaterai mon stockage en APFS et après je lance l’installation ou faut-il formater en HFS+, installer Mojave et l’OS convertira en APFS au premier démarrage ?

    Merci.
     
  16. macomaniac

    macomaniac Ouroboros
    Club MacG

    Inscrit:
    20 Septembre 2012
    Messages:
    57 383
    J'aime reçus:
    19 222
    :coucou: Yoskiz

    Je viens de faire le test dans l'environnement Mojave > sur un Fusion Drive CoreStorage > exportant un volume unique intitulé pour l'exemple FUSION -->

    • tu peux te faire une clé d'install démarrable de Mojave. Ou démarrer par internet (⌘⌥R = cmd alt R) > et je suppose qu'une fois Mojave devenu l'OS public le plus récent (attendre donc la sortie publique) => il doit y avoir téléchargement dans une image-disque en RAM d'un OS de secours 10.14 > permettant d'installer Mojave
    • il te suffit alors de lancer l'Utilitaire de disque > de sélectionner (dans mon exemple) le volume FUSION exporté par le Conteneur CoreStorage du Fusion Drive > menu : "Effacer" > et de choisir "APFS" (tout court) comme format --> le Conteneur CoreStorage est supprimé et il y a reconstruction d'un Conteneur apfs important 2 magasins de stockage physique Physical Stores sur les 2 partitions principales des 2 disques > avec exportation d'un volume apfs unique toujours intitulé FUSION.

    => en résumé : étant donné le volume d'un Fusion Drive CoreStorage > le menu : "Effacer" au format apfs de l'Utilitaire de disque (d'une session indépendante) --> assure la conversion globale CoreStorage => apfs tout en préservant le dispositif Fusion à 2 disques. Il n'y a plus alors qu'à lancer l'installation à destination du nouveau volume apfs.

    Je ne peux pas te dire > admis que tu aies effacé le volume du Fusion Drive CoreStorage en gardant le format jhfs+ de départ --> si une installation de Mojave à destination de ce volume effectue automatiquement la conversion à un Conteneur apfs Fusion du Conteneur CoreStorage Fusion. Simplement parce que jen n'ai pas essayé. Si j'effectue ce test > je te dirai l'issue ici.
     
    Yoskiz aime ça.
  17. Bonjour macomaniac,

    Merci beaucoup pour ces éléments, c’est très clair.

    Je vais prendre l’option Cmd alt R j’ai l’habitude de faire comme ça lors de clean installation.

    Plus qu’à patienter la sortie publique de Mojave. :)
     
  18. bompi

    bompi El Moderador
    Modérateur Club MacG

    Inscrit:
    12 Février 2004
    Messages:
    41 816
    J'aime reçus:
    3 121
    Au détour d'une page, je suis tombé sur le PDF de référence (ici).
    De quoi passer une bonne soirée...
     
    macomaniac aime ça.
  19. r e m y

    r e m y Cas clinique
    Club MacG

    Inscrit:
    4 Novembre 2000
    Messages:
    41 453
    J'aime reçus:
    4 224
    Oh! Les Tables de la Loi!

    Mais pour ce qui me concerne, je me contenterai dans un premier temps, de l'exégèse que ne manquera pas de nous en faire Macomaniac
     
  20. PulpyC

    PulpyC Nouveau membre

    Inscrit:
    19 Janvier 2019
    Messages:
    8
    J'aime reçus:
    0
    Bonjour a tous, j'ai malheuresement le meme erreur que les autres personnes qui me précédait, pourriez vous m'aider s'il vous plait
    de preference @macomaniac :)
    Code (Text):
    /dev/disk0 (internal):
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:      GUID_partition_scheme                         251.0 GB   disk0
       1:                        EFI EFI                     314.6 MB   disk0s1
       2:                 Apple_APFS Container disk2         250.7 GB   disk0s2

    /dev/disk1 (disk image):
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:      GUID_partition_scheme                        +2.1 GB     disk1
       1:                  Apple_HFS OS X Base System        2.0 GB     disk1s1

    /dev/disk2 (synthesized):
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:      APFS Container Scheme -                      +250.7 GB   disk2
                                     Physical Store disk0s2
       1:                APFS Volume Macintosh HD            5.2 GB     disk2s1
       2:                APFS Volume Preboot                 21.5 MB    disk2s2
       3:                APFS Volume Recovery                531.4 MB   disk2s3
       4:                APFS Volume VM                      1.1 GB     disk2s4

    /dev/disk3 (disk image):
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:                            untitled               +5.2 MB     disk3

    /dev/disk4 (disk image):
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:                            untitled               +524.3 KB   disk4

    /dev/disk5 (disk image):
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:                            untitled               +524.3 KB   disk5

    /dev/disk6 (disk image):
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:                            untitled               +524.3 KB   disk6

    /dev/disk7 (disk image):
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:                            untitled               +2.1 MB     disk7

    /dev/disk8 (disk image):
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:                            untitled               +524.3 KB   disk8

    /dev/disk9 (disk image):
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:                            untitled               +524.3 KB   disk9

    /dev/disk10 (disk image):
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:                            untitled               +12.6 MB    disk10

    /dev/disk11 (disk image):
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:                            untitled               +4.2 MB     disk11

    /dev/disk12 (disk image):
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:                            untitled               +1.0 MB     disk12

    /dev/disk13 (disk image):
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:                            untitled               +2.1 MB     disk13

    /dev/disk14 (disk image):
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:                            untitled               +524.3 KB   disk14

    /dev/disk15 (disk image):
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:                            untitled               +524.3 KB   disk15

    /dev/disk16 (disk image):
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:                            untitled               +1.0 MB     disk16

    /dev/disk17 (disk image):
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:                            untitled               +6.3 MB     disk17

    /dev/disk18 (disk image):
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:                            untitled               +6.3 MB     disk18

    /dev/disk19 (disk image):
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:                            untitled               +524.3 KB   disk19

    /dev/disk20 (disk image):
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:                            untitled               +2.1 MB     disk20
     
Modérateurs: Aliboron, bompi, daffyb
Chargement...