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

FSEvents




Il était une fois, un système d'exploitation appelé Be OS avec une conception osée et innovante. Ces idées audacieuses ne marchèrent pas toutes comme prévu cependant, et celles qui ont fonctionné ne furent pas assez nombreuses pour sauver le produit des autres forces non techniques, qui ont amené à sa déconfiture. Néanmoins Be OS a fait une grosse impression dans la communauté des Systèmes d'exploitation (OS). En particulier le système de fichiers, et les interfaces associées dans BeOS incluaient quatre caractéristiques dignes d'intérêt :
• La journalisation
• Un système de fichiers à méta-données extensible à la demande
• Des notifications asynchrones du système de fichiers
• Une indexation automatique des méta-données et un moteur de recherche intégré.

Ces caractéristiques s'associaient pour fournir une expérience utilisateur différente de celle de tout autre système d'exploitation de PC de l'époque. Les utilisateurs de Macs, en particulier, ont vu ces caractéristiques, ont compris leur intérêt, et les ont réclamées dans leur OS favori, à supposer qu'ils n'aient pas déjà déserté pour Be OS.

L'ouvrage Conception pratique du système de fichiers avec le système de fichiers Be décrit l'histoire et l'implantation de ces caractéristiques. Une version PDF gratuite est aussi disponible.

En 1997, Apple a acheté NeXT au lieu de Be, et basé Mac OS X sur le système NEXTSTEP. Initialement, Mac OS X n'avait aucune des caractéristiques du système de fichiers de Be énumérées ci-dessus. La pression pour les rajouter à Mac OS X, venue aussi bien de l'extérieur que de l'intérieur d'Apple s'est affrontée à une résistance importante des ingénieurs formés à la philosophie NeXT/Unix. Et c'est ainsi qu'a commencé un combat sur plusieurs années pour le futur des technologies du système de fichiers de Mac OS X : les partisans du Mac contre ceux de NeXT (les NeXTies).

A un moment (comme le dit la légende), les partisans du Mac ont gagné, et Apple a commencé à prendre un nouveau chemin. Mais cela prend du temps pour faire virer un bateau aussi gros que Mac OS X. Vue de l'extérieur, l'histoire technologique du système de fichiers de Mac OS X ressemble à une longue bataille de six ans pour implanter chacune des caractéristiques du système de fichiers de Be OS listée ci-dessus, toutes décriées par les NeXTies sur un point ou sur un autre, comme étant inefficaces et inutiles.

La journalisation a été ajoutée à HFS + ; Spotlight a apporté l'indexage automatique des méta-données et un moteur de recherche intégré ; de nouvelles APIs avec des attributs étendus ont apporté des méta-données extensibles à la demande. Maintenant, dans Léopard, le dernier morceau est arrivé : l'API de notification asynchrone du système de fichiers, sous la forme du framework FSEvents.

Les événements du système de fichiers, du déjà vu

Les utilisateurs de Mac férus de technique feront remarquer qu'une API de ce genre existait dans Tiger ; elle fut introduite pour rendre Spotlight possible. L'utilitaire /dev/fsevents surveillait toutes les entrées/sorties de fichiers qui passaient par le noyau de Mac OS X, et fournissait des notifications aux clients intéressés. Cela permettait au moteur de Spotlight d'indexer (et de ré-indexer) tout nouveau fichier, ou tout changement de fichier sans avoir recours à la scrutation. (La scrutation -polling- consiste à demander régulièrement si quelque chose a changé. Elle est complètement inefficace, et totalement infaisable comme façon de détecter des changements dans un système de fichiers tout entier).

L'API /dev/fsevents était privée, ce qui n'a pas empêché des hackeurs zèlés de jouer avec. Mais elle était privée pour de très bonnes raisons. Cela est en rapport avec le fonctionnement des notifications du système de fichiers.

Pour être informé de toutes les modifications relatives au système de fichiers, le mécanisme de notification doit intervenir au niveau du goulot d'étranglement pour toutes les entrées/sorties : le noyau. Mais le noyau est une maîtresse exigeante, avec des temps de latence et des restrictions de mémoire. Dans l'idéal, le code du noyau de /dev/fsevents devrait rendre chaque événement disponible pour les clients qui s'y intéressent, puis passer à la suite aussi vite que possible.

Si on revient à l'espace utilisateurs, les choses sont plus calmes. Les processus qui se sont signalés pour recevoir des notifications du système de fichiers via /dev/fsevent peuvent être indisponibles, en train de faire autre chose quand un événement arrive. C'est tout à fait normal dans l'espace utilisateurs, mais c'est tout à fait incompatible avec le besoin du noyau de voir les choses se réaliser immédiatement avec un minimum de besoins en mémoire et en CPU.

Que doit faire le noyau quand 10 000 modifications du système de fichiers interviennent en 2 secondes (disons, dans le cadre d'une installation de logiciel) et que l'espace utilisateur paresseux et stupide qui s'est inscrit pour recevoir les modifications du système de fichiers est en même temps trop préoccupé par d'autres choses, et n'a retiré de la queue aucune des notifications d'événements au cours des trois dernières secondes ?

Et bien, le noyau doit mémoriser ces événements en mémoire tampon, bien sûr. Ce qui veut dire qu'il doit sauvegarder tous les événements, et attendre que tous les clients intéressés aient finalement réussi à les prendre en compte. Mais les tampons (buffers) ne sont pas illimités. Et c'est particulièrement vrai pour le noyau. Que se passe-t-il quand les tampons sont pleins ?

Et bien, le noyau peut s'arrêter en attendant que de l'espace pour les tampons soit disponible. Mais voyez ce qui se passe quand un client se trouve bloqué sur une opération du système de fichiers parce qu'il n'y a pas de place dans la queue pour l'événement et que l'espace ne se libère jamais parce qu'un autre client, qui a besoin de lire les événements pour libérer l'espace du tampon est coincé sur le client qui s'est arrêté en attendant de l'espace. Salut, l'étreinte fatale.

La seule autre option possible est une allocation dynamique de mémoire, mais cela ne fait que repousser le problème. Dit simplement, ou bien vous limitez le nombre d'événements que vous pouvez mettre en tampon, et acceptez que parfois le tampon soit rempli, et vous allez perdre des événements, ou vous pouvez vous arranger pour utiliser une quantité de mémoire potentiellement illimitée.

Apple a choisi la première solution. Les tampons du noyau sont de taille fixe, et s'ils se remplissent à cause d'un client trop lent, des événements sont perdus. Ce qui signifie qu'un client au comportement défectueux peut affecter tout le monde.

Si bien que, non, /dev/fsevents n'est pas un bon candidat pour une API publique. Mais l'exigence de notifications asynchrones efficaces du système de fichiers demeure. Que faire ? Rentrons dans le framework FSEvents de Léopard. Il utilise une approche pragmatique pour fournir ces caractéristiques.

C'est un thème qui est récurrents dans toutes les nouvelles technologies de Léopard. Devant un problème technique épineux, FSEvents ne cherche pas à faire tout pour tout le monde. Au lieu de cela, il rétrécit habilement son objectif, en se concentrant sur ce qui est possible, et ce qui est probable. FSEvents fournit une solution "à 80 %" avec (presque) 100 % de fiabilité, plutôt que d'essayer d'être une solution "parfaite" capable de tout englober.

La conception et l'implantation de FSEvents

Il me semble qu'on est arrivé à la découverte fondamentale à la base de la conception de FSEvents en considérant une autre faiblesse de /dev/fsevents. L'API privée /dev/fsevents distribue les notifications en temps réel à tous les clients intéressés. Cela semble être la meilleure caractéristique de l'API, mais c'est en fait un gros handicap pour les clients. Tous les événements qui interviennent quand un programme client ne tourne pas ne seront pas vus par ce client. C'est pourquoi le processus d'indexage de Spotlight est lancé au moment où le système démarre, et continue à tourner aussi longtemps que l'ordinateur est sous tension. Cela doit être ainsi pour récupérer et utiliser tous les événements du système de fichiers.

Si n'importe quel autre programme veut observer tous les événements du système de fichiers, il doit faire la même chose : se lancer au démarrage, et continuer à tourner indéfiniment. Et puis, ne jamais se planter, parce que même un processus qui se relance immédiatement après un plantage peut rater quelques événements pendant le temps où il était hors service ; /dev/fsevent n'attend aucun processus.

Alors, comment cette prise de conscience a-t-elle conduit à la conception de FSEvents ? La réponse, c'est que résoudre le problème d'un client en fonctionnement constant fait aussi disparaître beaucoup d'autres problèmes. Voilà comment FSEvents s'y prend.

L'API /dev/fsevents peut seulement supporter un petit nombre de clients d'un très bon comportement. Spotlight en est un. Sous Léopard, FSEvents en est un autre. Le framework FSEvents repose sur un seul process démon (daemon) appelé fseventsd qui lit les événements depuis /dev/fsevents, et les écrit dans des fichiers log sur le disque (stockés dans le répertoire .fseventsd à la racine du volume que les événements concernent). C'est tout. C'est une solution de très haute technologie : seulement écrire des événements dans un fichier log. Ennuyeuse, pragmatique, mais tout à fait efficace.

Les programmes qui veulent utiliser l'API /dev/fsevents n'ont pas besoin de tourner en permanence. Ils peuvent être lancés à n'importe quel moment, et peuvent demander "Bon qu'est-ce qui a changé depuis la dernière fois où je fonctionnais" ? tant qu'ils savent où ils étaient dans le fichier log quand ils se sont arrêtés, le framework FSEvents peut efficacement repasser sur chaque événement qui s'est produit depuis lors, et répondre avec précision à la question.

Réaliste ? N'est-il pas aussi convenable d'appeler aussi cette solution "chargée de ses propres problèmes difficiles à résoudre" ? Quelle est la taille de ces fichiers log ? ne risquent-ils pas de remplir mon disque si je crée, modifie, efface des fichiers en permanence ? Est-ce que les fichiers log peuvent être raccourcis ? Que se passe-t-il si un processus n'a pas fonctionné depuis un an, puis veut soudain savoir ce qui s'est passé depuis ?

Le réalisme suppose des compromis. Oui, si fseventsd s'abreuvait au tuyau de /dev/fsevents et écrivait chaque événement élémentaire sur le disque, vous seriez à court d'espace disque très rapidement. Pour éviter cela, fseventsd n'écrit que les changements intervenus sur le répertoire de niveau le plus élémentaire. Le framework FSEvents, de son côté, peut seulement dire à ses clients " Quelque chose a changé dans le répertoire /foo/bar/baz".

Les clients de FSEvents doivent alors parcourir le répertoire qui a changé pour déterminer ce qui, exactement, est arrivé (en supposant qu'ils s'intéressent à ce niveau de détails). La séquence normale est d'enregistrer les notifications pour un sous-ensemble donné de l'arborescence du système de fichiers, faire un balayage initial de cet arbre, attendre des événements concernant un répertoire particulier, et comparer le nouvel état du répertoire avec l'état enregistré initialement.

Cela représente à coup sûr beaucoup de travail ennuyeux : enregistrer, balayer, récupérer les événements, balayer à nouveau, comparer. Et ce même code doit être écrit pour tout programme client de FSEvents, et il y a des conditions de déroulement cachées, si les programmeurs ne font pas attention. Le réalisme a un prix.

Mais les gains sont aussi tout à fait considérables. Plus de processus en démon ; lancer n'importe quand pour trouver ce qui a changé depuis la dernière fois. Pas de risque de clients au mauvais comportement susceptibles de laisser tomber des événements. Lisez les événements aussi lentement que vous le voulez. Plantez-vous, crashez-vous, relancez : c'est bon, vous ne manquerez aucun événement. Vous pouvez même revenir en arrière pour revoir des événements anciens.

Comme pour tous les mécanismes de notification du système de fichiers basés sur le noyau, y compris /dev/fsevents, il y a encore la possibilité de modifications du système de fichiers qui ne passent pas par le noyau. par exemple, un disque amovible peut être monté sur un autre ordinateur non Léopard, et modifié dessus. Quand il revient, le noyau local n'a aucune idée de ce qui a changé.

L'API FSEvents contient des fonctions de rappel pour ces situations, qui disent au client "Des changements inconnus sont intervenus. Vous devez refaire un balayage complet, puis vous brancher sur le nouveau flux d'événements à partir de là". Ce n'est certainement pas ce qu'un programme veut entendre, mais c'est la vérité inévitable, et FSEvents est en position frontale. En fait, c'est une forme de fiabilité. FSEvents ne va pas vous mentir.

Les fichiers log fseventsd sont écrits en format binaire compressé. Comme on ne garde que les modifications par répertoire, les modifications multiples d'un même répertoire dans un laps de temps de 30 secondes sont regroupées en un seul énement dans le fichier log. Le résultat est que, même avec avec une charge de travail de type serveur sur 24 heurs, sollicitant très fortement le disque, les fichiers log fseventsd ne vont grossir que de un à deux méga-octets par jour. Un usage normal n'en produira qu'une faible fraction.

Ça vaut mieux, parce que les fichiers log sont conservés à jamais . Enfin, à peu près. FSEvents utilise un compteur de 64 bits qui s'incrémente d'une façon monotone au gré des événements. Sauf manipulation malveillante du compteur, celui-ci ne reviendra pas à zéro pendant toute la durée de votre vie. Mais si cela arrive, ou si l'espace disque vient à manquer, ou si les logs sont explicitement supprimés (il y a une API publique pour cela), FSEvents va consciencieusement propager la nouvelle à ses clients : "Je regrette, c'est le moment de refaire un balayage complet".

Les événements sont identifiés par leur event id de 64 bits, qui n'a pas nécessairement de rapport avec la date et l'heure. Néanmoins, FSEvents a la possibilité de retrouver un event id qui correspond à une date et à une heure données.

Pour empêcher tout enregistrement des événements pour les changements sur un volume donné, créez seulemnt un fichier no_log dans le répertoire .fseventsd sur ce volume. Et pour le cas où cela n'irait pas sans dire, FREvents respecte les règles de contrôle d'accès de Mac OS X ; vous ne pouvez pas recevoir d'événements concernant des répertoires pour lesquels vous n'avez pas la permission de lire.

La barre latérale de Spotlight

Spotlight a été largement réécrit pour Léopard, et est notablement plus réactif. Cependant, l'application n'utilise pas les FSEvents. Elle continue à la place à s'abreuver au tuyau des /dev/fsevents, récupérant chaque événement quand il intervient. Cela peut paraître comme un défaut du framework FSEvents, mais c'est en fait la reconnaissance du statut de Spotlight comme utilitaire système.

Après tout, dans Be OS, l'indexage des méta-données était fait au niveau du système de fichiers à l'intérieur du code du système de fichiers BFS. Cela bien sûr ne fonctionnait que pour les volumes formatés BFS, et fut même plus tard éliminé de tout ce qui pouvait être dans l'espace utilisateurs, le code de tierces parties. Pour le meilleur ou pour le pire, l'indexation du système de fichiers à l'échelle du système est quelque chose que l'OS est le mieux à même de faire lui même, avec des APIs privées si nécessaire.

Le futur du système de fichiers

Avec l'addition d'une API publique pour les notification asynchrones du système de fichiers, Mac OS X a finalement accompli la parité fonctionnelle avec BeOS pour les branches majeures de la technologie des systèmes de fichiers. Il y a eu des compromis en route, mais aussi beaucoup de progrès. BeOS n'a jamais eu de log persistant des événements du système de fichiers, et il ne fournissait pas de méta-données d'indexation sur les volumes non BFS. Léopard sait faire cela, et plus (Spotlight peut en fait rechercher parmi des serveurs aussi), tout cela avec une collection très conventionnelle de bibliothèques de l'espace utilisateurs, et des démons qui tournent au dessus de quelques ajouts très élémentaires au noyau.

Il a souvent semblé que Apple devait être poussé, bousculé, exhorté sur la voie du futur des technologies du système de fichiers, mais enfin, elle est revenue à la raison. Oui, il y a eu des chaos sur la route, et les choses n'ont certainement pas tourné exactement comme je les attendais. Mais à la fin, c'est le résultat qui compte.

Les développeurs de Mac OS X ont maintenant tous les outils dont ils ont besoin, pour faire des choses très intéressantes avec le système de fichiers -et cela inclut Apple elle même. Comme nous le verrons, je me sens vraiment enthousiasmé avec Léopard, utilisant en fin de compte toutes les caractéristiques qu'ils ont ajoutées à l'OS avec tant de réticence pendant ces six dernières années. En fait, la caractéristique la plus emblématique de Léopard n'aurait pas été possible sans les FSEvents.

Quand au système de fichiers lui même pouvez-vous croire que nous sommes encore sous HFS + ? C'est vrai, les rumeurs d'une apparition de ZFS comme système de fichiers par défaut dans Léopard ne sont pas arrivées à maturité.

Les efforts pour porter ZFS sous Mac OS X sont en route, et Léopard est livré avec un pilote en lecture seule du système de fichiers ZFS, mais c'est tout pour l'instant. Un pilote ZFS lecture/écriture est apparu dans quelques pré-versions précoces de Léopard, et fera sans doute son apparition dans une future version de Mac OS X. (Une version béta est disponibles pour les membres d'ADC).

ZFS remplacera-t-il jamais HFS + comme système de fichiers par défaut de Mac OS X ? L'avenir le dira, mais il est évident que à la fin, quelque chose devra remplacer HFS +. Est-ce que ce sera ZFS, ou un nouveau système de fichiers développé par Apple, ou quelque chose d'autre entièrement nouveau ? L'été dernier, j'ai écrit :

Bien que je me satisferais de ZFS, je crois qu'Apple a un point de vue unique sur l'informatique, qui pourrait la conduire à un système de fichiers maison, avec quelques attributs intéressants. Quand un telle chose pourrait-elle apparaître ? Pas dans Léopard, semble-t-il, en tout cas pas dans 10.5.0.

Il est possible que le port complet de ZFS soit disponible dans le cadre d'une des versions 10.5.x, mais je me résigne plutôt à devoir attendre Mac OS X 10.6, ou plus tard, pour que quelque chose remplace HFS + comme système de fichiers par défaut dans Mac OS X. La bonne nouvelle, c'est que quand finalement il arrivera, toutes ces APIs grandioses du système de fichiers seront là à l'attendre.