1. John Siracusa
    1. Mountain Lion
      1. Introduction
      2. Achat et installation
      3. Changements d'interface (1)
      4. Changements d'interface (2)
      5. Changements d'interface (3)
      6. Applications (1)
      7. Applications (2)
      8. Applications (3)
      9. Applications (4)
      10. Applications (5)
      11. iCloud(1)
      12. iCloud(2)
      13. iCloud(3)
      14. Gatekeeper(1)
      15. Gatekeeper(2)
      16. Retina et HiDPI
      17. Fourre-tout (1)
      18. Fourre-tout (2)
      19. Fourre-tout (3)
      20. Fourre-tout (4)
      21. Fourre-tout (5)
      22. Fourre-tout (6)
      23. Recommandations
      24. Deux pères, un fils
    2. Lion
      1. Introduction
      2. Installation
      3. Revoir les fondamentaux
      4. Redimensionnement des fenêtres
      5. Et voici pour les cinglés
      6. La gestion des fenêtres
      7. Le modèle de document
      8. le modèle des processus
      9. Les éléments internes (1)
      10. Les éléments internes (2)
      11. ARC
      12. Le système de fichiers
      13. Ses modifications dans Lion
      14. Documents, résolution
      15. Le Finder
      16. Mail, Safari
      17. Fourre tout (1)
      18. Fourre tout (2)
      19. Recommendations
    3. Snow Leopard
      1. Introduction
      2. Le ticket d'entrée
      3. L'installation
      4. Nouvel aspect
      5. Détails internes
      6. Quick Time X
      7. Système de fichiers
      8. Faire plus avec plus
      9. LLVM et Clang
      10. Les blocs
      11. Concurrence
      12. Grand Central Dispatch
      13. Asynchronicité
      14. Open CL
      15. La différence...
      16. Quick Time Player
      17. Le Dock
      18. Le Finder
      19. Exchange
      20. Performances
      21. Fourre tout (1)
      22. Fourre tout (2)
      23. Le futur
    4. Leopard
      1. Introduction
      2. L'héritage
      3. Nouvel aspect 1
      4. Nouvel aspect 2
      5. Le noyau
      6. 64 bits
      7. FS Events
      8. Core animation
      9. Quartz GL
      10. Core UI
      11. Détails internes
      12. Le Finder
      13. Le Dock
      14. Time Machine
      15. Performances
      16. Pot pourri
      17. Demain
    5. Tiger
      1. Introduction
      2. Retour sur le passé
      3. Nouvel aspect de Tiger
      4. Mises à jour du noyau
      5. Le lancement
      6. Les méta-données
      7. Attributs étendus
      8. Listes de contrôle d'accès
      9. Spotlight 1
      10. Spotlight 2 : analyse et potentiel
      11. Types de fichiers
      12. Méta-données : la fin
      13. Quartz
      14. Quartz 2D Extreme
      15. Core Image
      16. La vidéo sous Tiger
      17. Dashboard
      18. Le Finder
      19. Les performances
      20. Pot pourri
      21. Conclusion
    6. Panther
      1. Introduction
      2. Les précédents
      3. L'installation
      4. Nouvel aspect
      5. Performances
      6. Changement rapide d'utilisateur
      7. Gestion des fenêtres
      8. Exposé
      9. Le Finder
      10. Performance du Finder
      11. Toujours le même
      12. Safari
      13. XCode
      14. Conclusion
    7. Jaguar
      1. Introduction
      2. Le nom
      3. L'installation
      4. Modifications d'Unix
      5. Dévelopeurs...
      6. Quoi de neuf
      7. Rendezvous
      8. Quartz Extrême
      9. Performance
      10. Compositions
      11. Le Finder
      12. Applications
      13. Sherlock
      14. Le portrait
    8. Puma
      1. Prelude
      2. Introduction
      3. Installation
      4. Réglages système
      5. Performance
      6. Redimensionnement des fenêtres
      7. Utilisation de la mémoire
      8. Diagnostics de mémoire
      9. L'environnement Classique
      10. L'interface Utilisateur
      11. Le Finder
      12. Extensions de fichiers
      13. Divers, conclusion
    9. Cheeta (Mac OS X 10.0)
      1. Qu'est ce que Mac OS X
      2. Installation
      3. Le démarrage
      4. Utilisation de la RAM
      5. Performance
      6. Performance des applications
      7. Stabilité
      8. L'interface utilisateur
      9. Le Finder
      10. Le navigateur du Finder
      11. Le Finder (divers)
      12. L'interface utilisateur
      13. Os X Classique
      14. Système de fichiers
      15. Unix
      16. Applications
      17. Conclusion
    10. Les débuts de MacOsX
      1. 1999 : OSX DP2
      2. 2000 : Quartz et Aqua/a>
      3. Fin de la lune de miel
      4. la première bêta publique
      5. 2001 : Mac OS X 10.0
      6. Un investissement
    11. Finder Spatial
      1. Introduction
      2. Interfaces spatiales
      3. Le Finder spatial
      4. Le concierge
      5. Un nouveau Finder
      6. Le browser
      7. Le browser spatial
      8. Finder et méta-données
      9. Les modèles
      10. Pensées finales

Lion (13)




Les modifications du système de fichiers dans Lion.

Nous en arrivons finalement au cœur du sujet. Dans Lion, que dit Apple à dieu, de la mort du système de fichiers " pas maintenant".

C'est vrai, le seul système de fichiers sur lequel vous pouvez installer Lion par défaut est notre vieil ami HFS+. Comme je l'ai dit précédemment, je suis sûr qu'Apple est très consciente des limitations de HFS+, et devrait compter son incapacité à trouver un successeur comme steward de la plateforme parmi ses (rares) échecs. Mais il semble que cela prendra beaucoup plus longtemps dans la feuille de route du système de fichiers d'Apple pour revenir dans la course après le recul sur ZFS.

Pourtant, il y a quelques modifications du système de fichiers dans Lion, quelques unes qui sont significatives, à vrai dire. Le plus important est l'introduction par Apple de la première solution pour créer un gestionnaire de volume logique : Core Storage.

Dans les versions précédentes de Mac OS X (ou de Mac OS classique en l'occurrence), un seul disque physique pouvait contenir un ou plusieurs volumes. Autrement dit, la connexion du disque au Mac faisait apparaître une ou plusieurs icônes de disque dur dans le Finder. De loin, le cas le plus courant consiste à n'avoir qu'un seul volume sur chaque disque physique. Mais les utilisateurs de Mac avec des besoins plus complexes (par exemple ceux qui ont installé plusieurs versions du système d'exploitation pour les tester ou en faire la critique) tirent pleinement avantage de la possibilité de scinder un seul disque physique en de multiples volumes indépendants.

Le rôle de HFS+ dans l'affaire est révélé par la nomenclature d'Apple. HFS+ est un " format de volume". Il vient à l'esprit qu'il doit y avoir quelque chose au dessus de HFS+ pour gérer les multiples volumes qui peuvent exister sur un seul disque, de la même façon que HFS+ gère les multiples fichiers et dossiers qui existent à à l'intérieur d'un seul volume. Et c'est ce qui se passe. Apple supporte plusieurs variantes de ce qu'elle appelle les "cartes de partition". (Les "partitions sont les régions d'un seul disque divisé en volumes avec un volume par partition. La carte de partition actuellement privilégiée par Apple est de la variante GUID").

La gestion des volumes logiques est un terme général, qui implique habituellement d'autoriser des relations plus souples entre les disques et les volumes que celles traditionnellement fournies par les cartes de partition. Dans le cas de l'Apple Core Storage, la caractéristique essentielle est la possibilité pour un seul volume de se répartir parmi plusieurs disques physiques.

Cela est un peu caché par une volée de terminologie nouvelle qui décrit les nouvelles couches de la pile de stockage. Tout en haut se trouve Groupe Volume Logique, qui peut contenir un ou plusieurs Volumes Physiques. Un Volume Physique fournit du stockage ; ce peut être un seul disque physique, un fichier d'image disque, ou même un périphérique RAID. Une Famille Volume Logique contient un ou plusieurs Volumes Logiques, chacun d'eux fournissant un cadre vide dans lequel (en fin de compte!) un format de volume comme HFS+ peut résider.

Avez-vous tout compris ? Ne vous inquiétez pas si ce n'est pas le cas. La seule chose qu'il vous faut comprendre, pour l'instant, c'est que Core Storage fournit un ensemble d'abstractions beaucoup plus riche au dessus du format de volume. La question suivante est évidente : que fait Lion avec Core Storage ?

Si vous entretenez des visions d'un stockage en pool de style ZFS, laissez moi tuer cela dans l'œuf. Il n'y a pas d'IUG familière pour créer des volumes répartis, et les outils que fournit la ligne de commande sont rudimentaires, et, selon mes tests limités, ne semblent pas supporter toutes les caractéristiques ostensiblement permises par Core Storage.

Le but de Core Storage dans Lion est discrètement caché dans la part du gâteau Famille Volume Logique. Les Familles Volume Logiques n'exportent pas seulement des Volumes Logiques, elles contiennent aussi des propriétés qui s'y appliquent. Un ensemble de ces propriétés dans Lion permet l'encryptage complet du disque.

Bien qu'Apple utilise le nom de marque FileVault pour cette caractéristique, cela n'a absolument rien à voir avec la caractéristique de même nom des précédentes versions de Mac OS X. L'incarnation précédente de FileVault encryptait le répertoire maison d'un utilisateur individuel en le stockant dans une image disque encryptée. Cela présentait toutes sortes de complications pour des opérations courantes, et FileVault a acquis une horrible réputation de faible compatibilité avec des logiciels existants (y compris certains d'Apple comme Time Machine).

FileVault dans Lion n'encrypte pas uniquement les répertoires maison des utilisateurs, il n'utilise pas des images disque encryptées. A la place, c'est une implémentation complète par Apple de l'encryptage du disque complet. Cela signifie que chaque octet de donnée qui constitue un volume est encrypté. Qui plus est, cet encryptage est complètement transparent à tout logiciel (y compris l'implémentation de HFS+ lui même) parce qu'il prend place dans une couche au dessus du format de volume, une couche que le logiciel d'application ne voit pas du tout.

Pour avoir utilisé un produit tiers d'encryptage de tout le disque pendant des années, je peux vous assurer que cette approche fonctionne admirablement bien. Elle est effectivement entièrement transparente, et les seuls problèmes de compatibilité que j'ai rencontrés impliquaient des mise à jour du système d'exploitation. (Quand on passe de Léopard à Snow Léopard, une nouvelle version du logiciel d'encryptage est nécessaire. Il est vraisemblable que cela ne sera plus un problème maintenant que cette caractéristique est construite à l'intérieur de l'OS).

Autoriser l'encryptage de tout le disque est facile sous Lion. L'onglet FileVault de la vitre de préférences sécurité et confidentialité guide prudemment l'utilisateur tout au long du processus en lui présentant des explications claires avec une dose très généreuse de mises en garde.

figure

L'encryptage de tout le disque avec FileVault.

Chaque utilisateur autorisé à décrypter le disque doit entrer son mot de passe pour le faire. Ensuite, une clé de récupération générée automatiquement est proposée, avec la suggestion d'en faire une copie et de la stocker dans un endroit sûr. C'est le dernier recours au cas où l'utilisateur oublierait le mot de passe de son compte. Un avertissement solennel concernant la perte de données accompagne cette information.

figure

la clé de récupération de FileVault : votre dernier recours.

Les gens vont-ils vraiment recopier cette clé et la stocker dans un endroit sûr ? Apple semble avoir des doutes, parce que l'écran suivant demande si vous voulez qu'Apple enregistre la clé de récupération pour vous. Il n'y a pas de choix par défaut à cette question, ce qui est tout à fait convenable, pour ce qui me concerne. La plupart des utilisateurs devraient probablement autoriser Apple à conserver leur clé de récupération, ce qui fait que l'option par défaut peut être considérée comme une possibilité d'accès par les geeks et les nerds de la sécurité.

Si vous choisissez de faire confiance à Apple, vous devez rentrer des réponses pour trois questions personnelles de votre choix. Le dialogue prétend que personne, pas même Apple, ne peut accéder à votre clé de récupération sans la réponse à ces questions. On a vu des déclarations comme celles-ci auparavant, mais je suis enclin à penser qu'Apple a appris des erreurs des autres.

Pour finir, Apple insiste pour qu'une partition de récupération soit présente sur le disque qui doit être encrypté. S'il n'y en a pas, ou si elle ne peut pas être créée (par exemple, parce qu'elle utilise une mauvaise carte de partition ou parce que sa création déplacerait une partition Boot Camp en quatrième position ce qui la rendrait non démarrable), l'encryptage ne pourra pas être poursuivi. (C'est un peu ennuyeux que ce test soit fait tout à la fin du processus).

En supposant qu'une partition de récupération existe ou peut être créée, un redémarrage est nécessaire pour autoriser l'encryptage. Lors du re-démarrage, un écran qui ressemble beaucoup à l'écran d'authentification de Lion (mais qui ne contient que les utilisateurs autorisés à décrypter le volume) apparaît immédiatement. Sélectionnez un utilisateur, et entrez le bon mot de passe de login, et le processus de démarrage réel commence. Même si auto-login est invalidé, vous allez démarrer directement sur le compte dont le mot de passe vient juste d'être entré.

En repassant sur la vitre de préférences de FileVault, on voit une estimation du temps qui reste avant que le processus d'encryptage soit complet. L'encryptage intervient de façon transparente en tâche de fond, ce qui est une bonne chose parce que cela prend longtemps. Pendant qu'il fonctionne, vous pouvez utiliser des applications, faire un log-out, redémarrer, et utiliser généralement votre Mac comme vous le feriez normalement, sans perturber le processus d'encryptage.

Si des utilisateurs sont incapables de décrypter le disque, ils peuvent être autorisés à le faire en entrant leur mot de passe d'authentification.

figure

autoriser plus d'utilisateurs à accéder au disque encrypté.

La sortie de la commande diskutil list semble un peu étrange (comparée à la précédente) :

figure

Fig. 1 :

Ce qui apparaissait précédemment comme un seul disque se présente maintenant comme deux. L'un contient les deux volumes non encryptés (Recovery HD et Timex) plus un nouveau volume Core Storage, et l'autre contient l'incarnation montée du nouveau volume encrypté (en fait, en cours d'encryptage, dans ce cas). En utilisant la variante spéciale Core Storage de la liste de commande (diskutil cs list), on récupère plus de détails, dont la plupart sont compréhensibles après la revue de terminologie qui précède.

figure

Lion ne rend par particulièrement facile l'encryptage des disques autres que celui de démarrage. L'application Utilitaire de disque peut supprimer l'encryptage pour un volume, changer le mot de passe d'encryptage du volume, ou reformater un volume avec l'encryptage validé (en effaçant toutes les données présentes sur le volume dans l'opération), mais il n'y a pas d'option pour encrypter un volume facilement sans l'effacer.

Les outils en ligne de commande à la rescousse : diskutil peut avec bonheur encrypter n'importe quel volume que vous désignez sans l'effacer d'abord. En réalité, le processus consiste à le convertir en un volume Core Storage qui peut en option inclure l'encryptage. Procédons à l'encryptage du volume Timex qui apparaît comme disk1s4 dans le précédente sortie de diskutil list.

figure

Comme l'indique la sortie de la commande, le volume est légèrement réduit pour permettre les entêtes de Core Storage, puis la couche des composants de gestion du volume logique est créée, à la fin de laquelle se trouve le nouveau volume logique. Aucun redémarrage n'est nécessaire pour commencer l'opération, qui intervient de façon transparente en tâche de fond, comme lors de l'initialisation avec l'IUG. La commande diskutil cs list montre maintenant une partie de Logical Volume Groups, chacun étant déclaré dans un processus d'encryptage. La quantité exacte de données encryptées, et ce qui reste à encrypter sur chaque volume sont aussi listés.

figure

A tout moment, le processus d'encryptage peut être inversé (en utilisant l'Utilitaire de disque, l'onglet FileVault de la vitre de Préférences Sécurité et confidentialité, ou la ligne de commande diskutil. Le processus de désencryptage intervient aussi en tâche de fond.

La modification du mot de passe d'encryptage pour un disque ne requiert pas un long processus de désencryptage ou de réencryptage. Je suppose que FileVault dans Lion fonctionne comme les autres solutions d'encryptage de tout le disque, du fait que, ce que le mot de passe déverrouille réellement, est la clé réelle d'encryptage pour le volume. La modification du mot de passe d'encryptage n'a besoin que de décrypter, puis de réencrypter la clé d'encryptage, ce qui est peu.

Les caractéristiques d'encryptage pour lesquelles Apple a choisi de proposer un accès en IUG en révèlent beaucoup sur les intentions d'Apple. D'abord, c'est complètement transparent. Les seuls changements en ce qui concerne l'utilisateur est que l'écran d'authentification est passé au tout début du processus de démarrage. Il n'y a pas de mot de passe séparé à se remémorer ; le mot de passe de login de l'utilisateur décrypte le disque. La même chose vaut pour tout autre utilisateur avec un compte sur le système.

Les mots de passe d'authentification sont seulement associés au disque de démarrage. L'utilisation de mots de passe d'authentification pour encrypter des disques qui peuvent passer d'un Mac à un autre peut porter à confusion. Cela explique en partie pourquoi il n'y a pas d'option en IUG pour encrypter des disques non démarrables. L'autre élément de cette décision est vraisemblablement que FileVault est focalisé sur les utilisateurs de mobiles. Aucun des portables d'Apple n'a plus d'un disque interne, et le partitionnement est rare, et probablement fait par des utilisateurs qui en savent assez pour envisager un utilitaire en ligne de commande afin d'autoriser l'encryptage de leurs volumes non démarrables.

L'encryptage et le décryptage transparent, une compatibilité logicielle parfaite, une IUG familière avec d'amples garde-fou pour les utilisateurs non-geek, que ne pourrait-on pas aimer ? Ah, et je suis sûr que vous vous posez la question de la performance. Toute forme d'encryptage complet du disque bénéficie du déséquilibre actuel entre la puissance du CPU et la rapidité du disque. En presque toute circonstance, le CPU de votre Mac passe son temps à se tourner les pouces avec rien à faire. Cela est particulièrement vrai pour les opérations qui impliquent beaucoup d'accès disque.

L'encryptage du disque complet tire avantage de la surabondance à peu près omniprésente des cycles CPU pour introduire les petits bouts de travail que requièrent l'encryptage et le décrytptage des données sur le disque. Apple utilise aussi les instructions spécifiques AES et le matériel sur les derniers CPUs d'Intel pour réduire encore la surcharge du CPU. Le résultat final, est que les utilisateurs normaux auront du mal à remarquer toute réduction de performance quand l'encryptage est validé. Sur la base de mon expérience avec les caractéristiques des pré-versions de Lion, je pense fermement à valider l'encryptage sur tout portable Mac avec lequel j'envisage de voyager.


Le futur du système de fichiers.

L'encryptage du disque qui fonctionne effectivement, plus quelques caractéristiques de base de gestion des volumes logiques, tout cela c'est bel et bien. Mais où cela nous laisse-t-il sur le front du système de fichiers ? Peut-être que les choses ne sont pas aussi mauvaises qu'elles le semblent. Ce qui suit n'est que spéculation, mais étant donné le vide d'information d'Apple sur tout ce qui concerne le système de fichiers, c'est tout ce que j'ai pour le moment.

Core Storage est sans doute la modification du système de fichiers la plus significative dans l'histoire de Mac OS X. Pensons à ce qu'il fait. Core Storage est responsable de la gestion des blocs de données qui constitue les différents volumes logiques sur un disque. Pour cela, il a sans doute un ensemble des structures de méta-données pour traquer l'espace alloué et l'espace libre, et pour se figurer quels blocs appartiennent à quel volume.

Maintenant, imaginez que ces blocs commencent à se réduire jusqu'à ce qu'ils aient la taille de, disons, des fichiers individuels. Et à la place des volumes, imaginez que ces blocs de la taille d'un fichier appartiennent à des répertoires. D'accord, c'est difficile, mais une fois encore, c'est tout ce dont nous disposons. En supposant qu'Apple soit satisfaite de la façon dont Core Storage fonctionne, elle a en fait mis en place son premier code entièrement nouveau qui réalise quelques unes des fonctions de base d'un système de fichiers. Si Apple était ainsi tentée, il semble techniquement plausible, au moins, qu'elle puisse étendre ce travail à un nouveau système de fichiers maison.

Avec ZFS hors jeu, Btrfs vraisemblablement éliminé à cause de problèmes de licence, et le futur développement de ReiserFS incertain, il est difficile de savoir où Apple pourrait trouver une système de fichier moderne dont elle a désespérément besoin autrement qu'en le créant elle-même.

Il y a quelque chose que j'attends depuis des années. J'aurais certainement accueilli ZFS les bras ouverts, mais j'étais aussi confiant dans la capacité d'Apple à créer son propre système de fichiers adapté à ses besoins particuliers. Cette confiance demeure, mais la distraction de ZFS peut avoir ajouté des années à l'emploi du temps.

En même temps, quelques âmes courageuses sont encore déterminées à apporter ZFS à Mac OS X. Je leur souhaite bonne chance, mais je préfèrerais de beaucoup une solution supportée par le vendeur de l'OS. Apple, le gant est jeté ; il est temps d'aboutir.