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 264
    J'aime reçus:
    3 376
    Bonsoir à tous.

    Un peu curieux après la MàJ vers High Sierra, je me suis fendu d'un diskutil list dans une fenêtre de Terminal et voilà ce que j'ai obtenu.

    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 disk1         250.7 GB   disk0s2

    /dev/disk1 (synthesized):
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:      APFS Container Scheme -                      +250.7 GB   disk1

                                    Physical Store disk0s2

       1:                APFS Volume Macintosh HD            161.7 GB   disk1s1
       2:                APFS Volume Preboot                 19.2 MB    disk1s2
       3:                APFS Volume Recovery                520.0 MB   disk1s3
       4:                APFS Volume VM                      2.1 GB     disk1s4
     
    Sans vouloir déranger @macomaniac :) je me demande comment lire ces informations.

    J'y lis (mais je compte sur vous pour me corriger) que le disque physique de 251 GB est donc utilisé pour 300 Mo pour l'EFI, le restant étant dévolu au conteneur APFS.

    Jusque là, même en n'étant pas un spécialiste des systèmes de fichier, je vois (hum...)
    C'est après que je ne saisis pas tout (ou encore moins qu'avant selon les points de vue)

    -> Preboot : kesako ?
    -> VM : kesako ?

    Arrêtez-moi si je me trompe.
    APFS (comme JHFS) introduisent une distinction entre volume "logique" et volume "physique"

    Sur ma machine le conteneur (volume logique) s'attribue/gère les 250,7 Go disponibles.
    diskutil list me permet de connaitre l'utilisation de l'espace de stockage des volumes 1, 2, 3 et 4 "physiquement" représentés ?

    L'espace disponible n'est pas représenté parce que non affecté ?


    Voilà une somme de questions.
    Merci par avance.
     
    Moonwalker aime ça.
  2. da capo

    da capo abonné absent
    Club MacG

    Inscrit:
    12 Août 2001
    Messages:
    17 264
    J'aime reçus:
    3 376
    Visiblement, ce sujet ne fait pas recette mais, ma petite expérience de ce jour fera peut-être réagir les uns ou les autres.

    En résumé, je dois déployer une image disque (clone Windows Seven) sur 2 machines "vierges" et l'accès réseau est perturbé. Je choisis donc de copier sur un DD le dossier "Ghost" pour y accéder directement.
    Zut ! le DD est en NTFS, donc je ne peux pas écrire.
    Qu'à cela ne tienne, je lance Utilitaire de Disques pour faire une partition en ExFat.
    Sans me poser de question je clique sur partitionner, définit la taille de la partition et Go !

    Ce que je n'avais pas vérifié c'est à quel disque j'appliquais cette modification…
    La machine était lente, très lente… Pourquoi ?

    Il s'agissait de mon Disque Interne !

    Une fois le partitionnement terminé, j'ai pu retrouver sans problème mon disque et lui appliquer la transformation inverse.
    (J'ai dans l'entretemps pu rétablir un accès réseau et déployer les images sans avoir recours au DD externe)

    Mais, je me suis alors posé la question : cette opération (partition du disque de démarrage) était-elle possible aussi simplement en HFS+ ?
    Que se serait-il passé si la taille de la partition avait dépassé l'espace disponible ?

    Avis aux experts.
    Merci par avance.
     
  3. macomaniac

    macomaniac Ouroboros
    Club MacG

    Inscrit:
    20 Septembre 2012
    Messages:
    46 805
    J'aime reçus:
    16 347
    :coucou: da capo

    Ton sujet m'avait complètement échappé.

    Si je reviens à ton 1er tableau > tu t'aperçois qu'il se distribue en 2 plans --> celui des partitions du disque physique (tu en as 2) > et celui des volumes du disque logique (le Conteneur APFS).

    Le tableau montre clairement que l'APFS est un système de stockage combinant magasin de stockage physique et disque logique - à la manière du système de stockage CoreStorage (son prototype historique)

    La partition disk0s2 accueille le Physical Store APFS : c'est le magasin de stockage physique des écritures.

    Ce magasin se trouve importé (comme sa base de données) par un Conteneur APFS qui est un disque logique virtuel (comme l'était le Logical Volume du CoreStorage par rapport au Physical Volume qui était son magasin de stockage). C'est un espace-disque purement virtuel, de second ordre par rapport à l'espace du disque physique, et donc identifié comme un disk1 par rapport au disk0.

    Cet espace-disque logique supporte 4 volumes logiques (un peu comme l'espace d'un disque physique peut supporter plusieurs volumes). Pour cultiver l'analogie > ces volumes sont identifiés comme des "tranches logiques" (slices ou partitions) de l'espace-disque du Conteneur : disk1s1 > disk1s2 > disk1s3 > disk1s4 (càd. disk1_slice1 etc.).

    Mais ce n'est qu'une analogie > parce que les volumes logiques APFS ne sont pas de réelles partitions du disque du Conteneur (parce que déjà le Conteneur n'est pas un disque physique, mais un disque logique virtuel). Car une partition commence à un bloc n° tant d'un espace-disque et finit à un bloc n° tant. Au bloc suivant commence une autre partition etc.

    Mais comme les volumes APFS sont extensibles > cela veut dire qu'il n'occupent pas une tranche pré-découpée sur l'espace-disque virtuel du Conteneur. Ils ont un point de montage (le point défini par leur système de fichiers à partir duquel ils montent en tant que volumes sur l'espace-disque du Conteneur) mais sans avoir de limite d'extension (sauf celle du Conteneur global).

    Il y a autant de systèmes de fichiers que de volumes > donc 4 définissant 4 point de montage sur l'espace-disque logique du Conteneur. Un peu comme s'il y avait aux quatre coins d'un terrain 4 bases pour 4 joueurs > qui auraient à se partager l'ensemble du terrain de jeu.

    C'est assez troublant > cette modification de paradigme logique : on n'a plus des "tranches" de disque à proprement parler > mais des aires qui partent des 4 angles d'un carré, en quelque sorte. Chaque joueur ayant un espace angulaire du terrain de la taille de ses acquis (données) comme base > mais disposant potentiellement de tout le reste de l'espace libre du terrain pour son expansion.

    ----------

    Les 4 volumes ne sont pas quelconques : ils ont des rôles impartis -->

    Macintosh HD est le volume de l'OS et des comptes d'utilisateurs. Rien de changé ici dans ses fonctions.

    Preboot est le volume de pré-démarrage du volume Macintosh HD. Cette fonction est entièrement reprise du CoreStorage > où le Volume Logique CoreStorage avait besoin d'un pré-démarreur qui était son « booter ». Ce prédémarreur dans le CoreStorage était hébergé par le volume de la partition Recovery HD - lequel hébergeait donc 2 dossiers : celui du booter du CoreStorage et celui du RecoveryOS de secours. Avec l'APFS > ces 2 fonctions ont été réparties en 2 volumes distincts > Preboot monopolisant la fonction de booter du volume Macintosh HD. Ce qui montre que le volume-Système Macintosh HD ne monte pas tout seul ("à froid") --> il lui faut un démarreur auxiliaire.

    Recovery est le volume du RecoveryOS de secours. Ce volume n'est plus hébergé sur une partition séparée du disque physique (comme le Recovery HD classique) > mais est un volume logique qui a son point de montage sur l'espace-disque virtuel du Conteneur.

    VM est du nouveau à partir de l'ancien. C'est l'acronyme de Virtual Memory et il contient la sleepimage (le fichier stockant le contexte de la RAM avant la mise en sommeil). Ce fichier était traditionnellement localisé at: /private/var/vm/ sleepimage dans le volume démarré Macintosh HD. Rien n'a changé à l'arrivée en ceci : une fois le volume logique Macintosh HD démarré > le volume VM se trouve monté spécialement à l'emplacement du sous-dossier /private/var/vm du volume-Système démarré --> vm constituant donc son point de montage dans Macintosh HD. De cette manière > aussi longtemps que Macintosh HD est démarré > vm est la manifestation locale du volume VM et contient donc ce que contient VM : la sleepimage > directement adressable. À l'extinction du Système de Macintosh HD > VM est redémonté avec son contenu édité : la sleepimage.

    Les 2 volumes Preboot et Recovery ne sont pas montés lorsque le volume Macintosh HD est monté / démarré et le volume VM sous-monté at: /private/var/vm.

    ----------

    Pour tes dernières questions :
    Le système de fichiers jhfs+ possédait déjà cette "élasticité" lui permettant d'être étiré (pour absorber de l'espace libre) ou rétréci (pour dégager de l'espace libre avec lequel créer une autre partition et un autre volume). "Élasticité" capable de jouer en mode "live" (le volume impliqué maintenu monté sans démontage - càd. sans désactivation du système de fichiers).

    Le système de sockage CoreStorage avait la même "élasticité" > dans la mesure où il servait de support à un volume-hôte terminal (Macintosh HD) dépendant d'un système de fichiers jhfs+.

    Le système de stockage apfs hérite de la même élasticité - mode "live" compris.

    Si la taille d'une partition demandée excède l'espace disponible (= non occupé par des données) > jamais l'espace occupé par des données ne se trouve amputé --> la commande est avortée comme inadéquate à l'espace disponible pour un re-partitionnement.
     
  4. da capo

    da capo abonné absent
    Club MacG

    Inscrit:
    12 Août 2001
    Messages:
    17 264
    J'aime reçus:
    3 376
    En tout cas merci pour toutes ces précisions.
     
  5. Locke

    Locke What am I doing here?
    Modérateur Club MacG

    Inscrit:
    20 Juillet 2011
    Messages:
    27 551
    J'aime reçus:
    2 743
  6. r e m y

    r e m y Cas clinique
    Club MacG

    Inscrit:
    4 Novembre 2000
    Messages:
    41 437
    J'aime reçus:
    4 216
    Mais l'instantané de sauvegarde est nulle part et partout à la fois!

    Il ne s'agit pas, comme les sauvegardes locales de TimeMachine sur les portables (avant HighSuerra et l'APFS) de copier les fichiers à sauvegarder dans un dossier temporaire, mais de lister les fichiers correspondant à l'état de la machine à l'instant T en laissant les fichiers là où ils se trouvent sur le disque (les modifications ultérieures de ces fichiers étant enregistrées par APFS à part du fichier originel).
     
    iluro_64 aime ça.
  7. macomaniac

    macomaniac Ouroboros
    Club MacG

    Inscrit:
    20 Septembre 2012
    Messages:
    46 805
    J'aime reçus:
    16 347
    C'est comme la divinité pour Gustave Flaubert : « présente partout et visible nulle part ». [​IMG]
     
    bibicool16 et iluro_64 aiment ça.
  8. Locke

    Locke What am I doing here?
    Modérateur Club MacG

    Inscrit:
    20 Juillet 2011
    Messages:
    27 551
    J'aime reçus:
    2 743
    Selon l'article...
    ...s'il y a plusieurs instantanés, il faut bien qu'ils soient stockés quelque part.

    macgpic-1509024564-34442629091413-sc-jpt.jpg
     
  9. r e m y

    r e m y Cas clinique
    Club MacG

    Inscrit:
    4 Novembre 2000
    Messages:
    41 437
    J'aime reçus:
    4 216
    Ils sont stockés sous forme de "listes" répertoriant l'emplacement des fichiers sur le disque avec leurs diverses modifications selon l'heure de l'instantané.

    Ces listes, tout comme le catalogue principal de fichier d'ailleurs, je ne sais pas où elles sont archivées.
     
  10. Locke

    Locke What am I doing here?
    Modérateur Club MacG

    Inscrit:
    20 Juillet 2011
    Messages:
    27 551
    J'aime reçus:
    2 743
    Comme je teste macOS High Sierra dans mon vieux MBP de 2010, je n'ai pas encore vu le moindre instantané et comme je suis curieux, c'est juste pour savoir sous quelle forme ça se présente et où ?

    Sur le fond, ça fera une belle roue de secours (à court terme) pour tous ceux qui n'ont pas fait de sauvegardes.

    J'ai trouvé un petit problème avec le format APFS, si on fait une clean install et que l'on utilise ensuite Assistant migration, il y aura systématiquement la création d'un nouvel Administrateur. Par contre, si pendant l'installation on accepte la migration depuis un autre Mac, ce problème ne se présentera pas.
     
    durandal216 aime ça.
  11. r e m y

    r e m y Cas clinique
    Club MacG

    Inscrit:
    4 Novembre 2000
    Messages:
    41 437
    J'aime reçus:
    4 216
    À ce stade, seul TimeMachine t'en affiche la liste en redémarrant depuis recoveryHD

    Quand Apple aura mieux documenté ce point, il est probable que des développeurs s'en empare pour en tirer parti dans des utilitaires.
     
  12. macomaniac

    macomaniac Ouroboros
    Club MacG

    Inscrit:
    20 Septembre 2012
    Messages:
    46 805
    J'aime reçus:
    16 347
    :coucou: Locke

    J'avoue que je ne m'étais pas intéressé à la question, pour des raisons « pratiques » : je ne suis pas un utilisateur de «TimeMachine» mais de clones - aussi les subtilités de «TimeMachine» n'excitent pas spontanément ma faculté spéculative.

    Mais puisque tu en fais une question « théorique » > alors cela suffit pour stimuler ma faculté de raisonnement.

    ----------

    J'ai démarré sur la version APFS de High Sierra (que je n'utilise pas au quotidien). «Time Machine» y est désactivé et je maintiens ce statut. Mais cela n'empêche nullement de gérer des snapshots en manuel, sans le secours du logiciel graphique TM.

    Dans le «Terminal» > passer la commande :
    Code (Text):
    sudo tmutil localshapshot
    permet de créer un instantané local indexé par une date (la commande prend un petit moment à s'exécuter).

    Cet instantané local a-t-il bien été créé > alors même que j'ai maintenu la désactivation de «Time Machine» ? - pour le savoir > je passe la commande informative :
    Code (Text):
    sudo tmutil listlocalsnapshot /
    (il faut indique le point de montage du volume-cible - ici le volume démarré)

    J'obtiens en retour un :
    Code (Text):
    com.apple.TimeMachine.2017-11-03-172947
    Voici donc l'instantané local apfs (snapshot) que je viens de créer précédemment.

    ----------

    Ignorons pour l'instant la question de sa localisation > pour expérimenter son usage. Il est nécessaire de re-démarrer par ⌘R en mode Recovery. Le RecoveryOS sur lequel s'effectue le démarrage n'est en rien le RecoveryOS contenu dans le volume APFS Recovery > mais son clone créé à la volée dans un RAMDisk > ce qui fait que le démarrage s'effectue sur un disque indépendant du disque physique du Mac. Cela explique la lenteur aggravée de ce démarrage. C'est prouvé par une commande :
    Code (Text):
    hdiutil info
    dans le «Terminal» Recovery > qui retourne la liste de toutes les images-disques montées en volume : une image-disque de la taille de la Recovery (dans les 2 Go) se trouve désignée comme un fichier-RAM (ramfile) --> donc le disque est bien en RAM.

    Je lance l'option : "Récupérer une sauvegarde Time Machine" (alors que je n'en ai aucune sur un disque dédié à des sauvegardes TM classiques) --> l'application activée n'y voit aucun inconvénient > car une fois effectué le scan des volumes montés des disques attachés au Mac > elle affiche le volume de mon OS APFS comme source possible de restauration. Je le choisis > et le snapshot précédemment créé :
    Code (Text):
    com.apple.TimeMachine.2017-11-03-172947
    se trouve affiché comme source de restauration.

    J'active cette restauration (ce sera bien la première fois que ça m'arrive d'utiliser une restauration de type Time Machine) > et après un temps d'environ 15 à 20 secondes j'obtiens le message disant que le disque a été restauré à son état exact de la date du snapshot.

    Une re-démarrage automatique s'effectue > et me voici dans ma session recréée au contexte précis de la prise de l'instantané local.

    Je reconnais que ce résultat me paraît impressionnant. Pourquoi s'embêter à se mettre dans les affres avant une MÀJ de sécurité par exemple ? Par une commande dans le «Terminal» de l'OS :
    Code (Text):
    sudo tmutil localshapshot
    je crée un instantané local juste avant l'opération > et si j'ai des ennuis (genre : écran noir) > hop ! je démarre en mode Recovery (en RAM donc) > j'active la restauration TM d'après l'instantané local du volume de l'OS > et 20 secondes après j'ai tout restauré comme avant la MÀJ foireuse.

    Ce doit être un réflexe à prendre - en tout cas ça va plus vite qu'avec un clone.

    ----------

    Alors mézoùestdoncornicar - càd. où est stocké l'instantané local ?

    Des recherches en ligne de commande avec find et l'intitulé du snapshot ne donnent absolument rien.

    D'ailleurs il suffit d'un simple raisonnement pour exclure la possibilité que le snapshot soit socké comme un fichier parmi les fichiers du volume-Système -->

    • et si une foirade m'efface des kilomètres de fichiers du Système ? - si le snapshot était stocké comme un fichier dans les fichiers du volume > il serait balayé du même coup. Trop risqué.
    • il est stipulé dans le man de tmutil (version High Sierra) que la restauration à partir d'un snapshot restaure tous les volumes APFS du Conteneur impliqué (et pas le simple volume-Système). Peut-on raisonnablement imaginer qu'un fichier local du volume du Système pourrait servir de source à ce type de restauration "systémique" ou 'structurale" complète ? Non - ça ne me paraît pas vraisemblable.

    De fil en aiguille de cette spéculation "vagabonde" > je me dis que pour que le snapshot puisse restaurer pas moins que l'ensemble du Conteneur APFS > il faut qu'il ait une "position-racine" pour pouvoir exercer cette "fonction-racine".

    Je me décide donc à lancer une commande :
    Code (Text):
    diskutil verifyVolume disk1
    (où disk1 est l'identifiant de disque logique du Conteneur APFS global)

    J'obtiens un affichage d'opérations complexes > impliquant à la fois le dispositif-racine "collectif" du Conteneur et chacun des dispositifs locaux des volumes (un peu comme s'il s'agissait d'un "système de fichiers de systèmes de fichiers") > et vers la fin de la vérification > voici ce qui s'affiche :
    Code (Text):
    Checking the snapshot metadata tree
    Checking the extent ref tree
    Checking the snapshots
    Checking snapshot 1 of 1
    Eurêka ! Voici l'objet cherché et trouvé : le snapshot. Il n'appartient pas aux fichiers du volume monté > il appartient aux fichiers du système de fichiers APFS.

    Bref rappel : un système de fichiers ancré sur un en-tête de partition de disque définit un point de montage sur la partition > qui est le point de montage du volume (dev node). Le volume monte comme espace de répertoire affichant des écritures en forme de fichiers interprétables. Mais jamais le système de fichiers ne se montre lui-même comme un fichier du volume. Non : le système de fichiers est une "pré-structure" de fichiers, toujours extérieure au volume qui en est l'effet.

    Les snapshots (ou instantanés APFS) ne sont donc pas des fichiers résidents d'un volume > mais des composants du système de fichiers qui permet le montage du volume. D'après la vérification > un "fichier" (si je puis dire) intitulé le « snapshot metadata tree » --> "arbre de métadonnées de snapshots". La localisation est donc interne à la cause (le système de fichiers) > pas à l'effet (le volume monté).

    Ce qui explique qu'aussi longtemps qu'on ne reformate pas (n'efface pas le Conteneur APFS) > le snapshot reste indemne des péripéties des volumes montés à partir du système de fichiers APFS.

    Cette fantastique innovation doit quand même avoir des limites : je ne pense pas qu'un volume puisse être recréé en tant que volume s'il a été supprimé du Conteneur, car la « branche logique » lui correspondant dans l'« arbre logique » du système de fichiers doit avoir du même coup été coupée.

    Bonus : je m'explique la raison du démarrage Recovery sur un clone en RAM : il faut cette position indépendante d'aucun volume monté du Conteneur > pour que le « snapshot metadata tree » du système de fichiers-racine puisse avoir une puissance de restauration de tous les volumes du Conteneur APFS.
     
    #12 macomaniac, 3 Novembre 2017
    Dernière édition: 3 Novembre 2017
  13. da capo

    da capo abonné absent
    Club MacG

    Inscrit:
    12 Août 2001
    Messages:
    17 264
    J'aime reçus:
    3 376
    Alors là, je reste "pantois".
    Je suis coutumier du clonage hebdomadaire et, si je comprends bien ce que tu décris, le snapshot est rapide. Mais dans quelle mesure ?
    En utilisant CCC, de mon disque SSD interne vers un SSD externe, cette opération prend à peine quelques minutes pour environ 120 Go de données.

    Le snapshot est-il significativement plus rapide ?

    Quand TimeMachine procède à une forme de purge, peut-on imaginer un script contrôlé par le successeur de cron pour réaliser ces snapshots à des intervalles choisis et leur effacement de type FIFO ?
     
  14. r e m y

    r e m y Cas clinique
    Club MacG

    Inscrit:
    4 Novembre 2000
    Messages:
    41 437
    J'aime reçus:
    4 216
    La restauration d'un snapshot est quasiment instantanée car il n'y a aucune copie de fichiers. Les fichiers restent physiquement au même endroit sur le SSD. (C'est la magie d'APFS)
    Tout se passe au niveau du catalogue de fichiers du disque qu'il faut actualiser pour lui redonner la liste des fichiers et leur localisation physique au moment choisi de restauration.
     
  15. Locke

    Locke What am I doing here?
    Modérateur Club MacG

    Inscrit:
    20 Juillet 2011
    Messages:
    27 551
    J'aime reçus:
    2 743
    @macomaniac :coucou:

    Je n'en attendais pas moins de toi qui décortique d'une main experte les méandres des macOS. Donc j'avais bien compris le principe du fichier RAM(ramfile) qui est bien dans la mémoire de base, donc de façon virtuelle. Aucun problème non plus pour la création d'un fichier localshapshot via le Terminal, mais je pensais naïvement que cela se faisait automatiquement avec un quota de fichiers.

    C'est vrai que si on veut tester un logiciel, et que l'on fait juste avant un localshapshot, que si ça ne plaît pas qu'il suffit de redémarrer et de restaurer le dernier fichier localshapshot. Et ça c'est vraiment parfait et en effet bien plus rapide qu'une restauration d'un clone. Là, il n'y a rien à dire.

    Et voilà, j'ai la réponse à la grosse interrogation que je me posais. Maintenant je pense que je vais prendre le pli de faire un localshapshot via le Terminal lorsque je testerais des logiciels et vu que j'en teste pas mal, ça m'ira très bien en me faisant gagner du temps.

    Merci de tout le temps que tu nous consacres depuis un bon moment avec tes explications très techniques avec le Terminal. Et je pense que ce message devrait être épinglé en tête de section, car il est très informatif sur la nouveauté qu'est le format APFS et le début de ses profondeurs. :D
     
    bibicool16 aime ça.
  16. bompi

    bompi El Moderador
    Modérateur Club MacG

    Inscrit:
    12 Février 2004
    Messages:
    41 776
    J'aime reçus:
    3 110
    Apple a repris le fonctionnement de ZFS pour son APFS.

    Ce qui est contestable est l'utilisation de commandes liées à Time Machine alors que cela n'a strictement rien à y voir [et que, ironiquement, APFS et Time Machine n'ont pas l'air d'être pleinement compatibles pour le moment...]. Dans les bêtas, il y avait une commande apfs_snapshot bien pratique et elle a apparemment disparu (je n'ai pas encore installé HS).

    Il faut quand même manier ces instantanés (ainsi que les clones propres à APFS) avec un peu de prudence car ils sont exhaustifs : en revenant à un état antérieur, c'est la totalité du système de fichiers qui fait un retour arrière donc tout travail effectué entre-temps est perdu.

    Par ailleurs, avoir des instantanés a aussi des impacts sur l'espace occupé sur le volume.
    Lorsqu'on a fait un instantané, toute suppression d'un fichier qui existait à ce moment-là n'est que virtuelle : le fichier reste présent pour permettre le retour en arrière, même s'il n'apparaît plus à l'utilisateur.
    De même, toute modification d'un fichier pré-existant consomme de l'espace, même si on le réduit (on garde son état antérieur et son état modifié).

    Pour de petits fichiers, on s'en fiche un peu, mais pour des fichiers volumineux (films, bases de données), c'est plus épineux.

    Il devient donc de plus en plus difficile d'imaginer l'état exact de son volume ;)
     
  17. Locke

    Locke What am I doing here?
    Modérateur Club MacG

    Inscrit:
    20 Juillet 2011
    Messages:
    27 551
    J'aime reçus:
    2 743
    C'est aussi l'interrogation que j'ai : quelle est l'espace réel occupé d'un instantané local et est-il facile de l'effacer ?

    Et si on pouvait passer ce message en épinglé, nul doute que ce message nous en apportera plus.
     
  18. flotow

    flotow AppIeSpirit™
    Club MacG

    Inscrit:
    23 Mars 2004
    Messages:
    11 896
    J'aime reçus:
    1 870
    Petite question : pourquoi la création d'un instantané prend du temps sur APFS ?
    Sur ZFS, pour les quelques snapshots manuels que j'ai fait sur plusieurs centaines de GB, c'est instantané.
     
    #18 flotow, 5 Novembre 2017
    Dernière édition: 5 Novembre 2017
  19. bompi

    bompi El Moderador
    Modérateur Club MacG

    Inscrit:
    12 Février 2004
    Messages:
    41 776
    J'aime reçus:
    3 110
    Bug ? Compétence ? Qualité des développements ? Jeunesse du produit ? Mauvaises options ? Toujours en mode debug pour affiner les pilotes ? (j'en oublie)
    Tu as le choix.

    Sur ces systèmes de fichier, un instantané doit effectivement être quasi-instantané, un peu comme pour une VM.
     
  20. bompi

    bompi El Moderador
    Modérateur Club MacG

    Inscrit:
    12 Février 2004
    Messages:
    41 776
    J'aime reçus:
    3 110
    Pendant que j'y suis, j'épingle le fil.
     
    bibicool16 aime ça.
Modérateurs: Aliboron, bompi, daffyb
Chargement...

iOccasion - Achetez un produit Apple d'occasion

refurb Apple