Une brève rétrospective sur le système de d’exploitation de réseau de Sprite


Original: http://www.stanford.edu/~ouster/cgi-bin/spriteRetrospective.php

 

Sprite est un système d’exploitation de recherche développé par mon groupe de recherche à l’Université de Berkeley, entre 1984 et 1994. Quatre étudiants des cycles supérieurs et j’ai commencé le projet à l’automne 1984 parce que nous estimions que les systèmes d’exploitation actuels ne payaient pas une attention suffisante aux réseaux locaux. Il nous a semblé que prise en charge réseau a été ajouté de façon rapide et sale pour les systèmes qui ont été conçus pour fonctionner en autonome. En conséquence, des postes de travail en réseau ne fonctionnent pas bien ensemble. À l’époque, que nous avons commencé le Sprite, il y n’avait aucun bon réseau des systèmes de fichiers (NFS même n’existait pas encore) et gestion d’un réseau de stations de travail a été un cauchemar.

Principales réalisations

Notre objectif pour Sprite était de « faire droit de réseautage » en construisant un nouveau noyau de système d’exploitation à partir de zéro et le réseau de soutien dans le système dès le départ. Nous espérions créer un système où une collection de postes de travail en réseau se comporterait comme un seul système avec stockage et répartie uniformément entre les postes de travail de la puissance de traitement. Nous espérions que les utilisateurs serait en mesure d’exploiter la puissance de l’ensemble du réseau tout en préservant le comportement simple et facilité administrative d’un système traditionnel de temps partagé.

Je pense que nous avons atteint ces objectifs. Quatre réalisations techniques se distinguent dans mon esprit. Tout d’abord a été le système de fichiers réseau du Sprite, qui a démontré que les systèmes de fichiers réseau peuvent fournir un modèle utilisateur pratique sans sacrifier les performances. Système de fichiers du sprite permis tout en masquant complètement le réseau de partage de fichiers. Il a fourni le même comportement dans un environnement réseau qui utilisateurs verrait si ils ont tous couraient sur un système traditionnel de temps partagé. Périphériques d’e/s même pourraient être consulté unformly sur le réseau, et processus utilisateur pourraient étendre le système de fichier en mise en œuvre de son I/O et en nommant des protocoles à l’aide de pseudo-périphériques et les systèmes de fichier de pseudo. Dans le même temps, Sprite utilisé mise en cache du fichier agressif pour atteindre de hautes performances. Système de fichiers réseau du sprite était le plus rapide du monde jusque dans les années 1990.

Deuxième réalisation clé de sprite était son mécanisme de migration de processus, qui a permis le processus être déplacé de manière transparente entre postes de travail à tout moment. Avec migration de processus un seul utilisateur peut exploiter la puissance de nombreuses stations de travail simultanément, atteindre des accélérations de quatre ou plus sur les tâches courantes de système comme la recompilation. Le mécanisme de migration gardé la trace des machines ralentis, ils les utilisent pour la migration et expulsées processus migrés lorsque le propriétaire d’un poste de travail renvoie, pour que la migration n’a pas incidence sur le temps de réponse des utilisateurs actifs. Processus expulsées étaient ayant pour différentes machines ralentis ou exécutés sur leur machine à la maison. Sprite était l’un des seuls quelques systèmes où des processus de migration a été servie au jour le jour par une communauté importante d’utilisateurs.

(En toute honnêteté, il est à noter que le processus de migration a été compliquée à mettre en œuvre et difficile de continuer à fonctionner comme système évolué ; il n’est pas surprenant que la migration jamais trouvé sa place dans les systèmes d’exploitation grand public. Les meilleures implémentations de migration de processus se trouvent désormais dans les écrans d’ordinateur virtuel : l’API pour un ordinateur virtuel est plus facile d’encapsuler que celle d’un système d’exploitation modern. La mise en œuvre du mécanisme de migration machine virtuelle dans VMware était Mike Nelson, qui fut l’un des membres fondateurs du projet Sprite.)

Troisième réalisation clé de sprite était son image système unique. Le système et le processus de migration de fichiers fournie la preuve la plus évidente de l’image système unique, puisqu’ils ont fait de puissance de traitement et de stockage partageable entre les postes de travail. Mais de nombreuses autres manières Sprite regardé et senti comme un seul système. Il y avait partition un racine, un mot de passe fichier, zone d’un swap (dans le système de fichiers réseau), base de données un seul login et ainsi de suite. La commande « doigt » signalé tous les utilisateurs sur tous les postes dans le cluster de Sprite, pas seulement ceux sur le poste de travail où la commande a été appelée. Administration système était pas plus dure avec cinquante machines du réseau qu’avec dix, et ajout d’une nouvelle machine a été plus difficile que d’ajouter un nouveau compte d’utilisateur.

Image système unique du sprite a également appuyé des architectures d’ordinateur différent dans le même cluster. Nous avons élaboré un cadre pour la séparation d’informations indépendants de l’architecture des informations propres à l’architecture. Toutes les informations pour toutes les architectures étaient visibles en tout temps, laquelle Croix-développement simplifié, mais chaque machine utilisée l’information appropriée d’architecture dépendant lorsque c’était nécessaire.

Quatrième réalisation clé de sprite était son système de fichiers (EPA), qui ont démontré une approche radicalement nouvelle de la conception de système de fichier. LFS traités le disque plus comme un ruban, écriture des informations de façon séquentielle en grandes séries qui permettent de grande efficacité. Nous avons mis au point un nouveau mécanisme de collection d’ordures qui s’ouvre sans cesse de grandes étendues d’espace libre sur le disque. Le résultat était un système qui a écrit les petits fichiers sur le disque un ordre de grandeur plus vite que n’importe quel autre système de fichiers existant. En même temps il géré au moins autres opérations, telles que les lectures et écritures grands, ainsi que d’autres systèmes. Les systèmes de fichiers ont bien d’autres avantages, tels que la restauration rapide, la possibilité de stocker des informations sur le disque sous forme compressée et la possibilité de faire varier la taille du bloc d’un fichier dans un fichier. Les techniques de l’EPA ont été adoptés dans les produits de système de fichier commercial telles que celles de NetApp et servent également de nouveaux dispositifs tels que la mémoire flash.

Tout au long du projet de Sprite, nous avons essayé de caractériser le comportement du système et pour utiliser cette information pour guider les développements futurs. Certains de nos résultats les plus importants étaient les mesures que nous avons fait. La Fondation du projet reposait en partie sur les mesures de système de fichier réalisées sur des systèmes de temps partagés en 1984 et 1985. On fait des mesures supplémentaires d’utilisation de Sprite en 1991 pour voir comment les patrons avaient changé et analyser l’application possible de la mémoire non volatile dans les systèmes en réseau.

Peut-être le plus important accomplissement de tous est que nous avons pu faire fonctionner, pas seulement pour nous-mêmes mais pour une communauté d’utilisateurs qui en comptait aussi haut que 80 ou plus à la pointe du projet le système. Beaucoup de ces utilisateurs dépendaient de Sprite pour l’ensemble de leurs besoins informatiques au quotidien, tels que le courrier et l’impression. Pour une période de plusieurs années, il était courant de voir les connexions simultanées 25-35, dont seulement une demi-douzaine de développeurs de Sprite. Je ne connais qu’un seul autre projet Université qui a mis au point un nouveau noyau de système d’exploitation à partir de zéro et utilisé pour soutenir une communauté d’utilisateurs ce grand pour ce long ; Ce projet a été de Multics, qui a été réalisée au MIT dans la fin des années 1960.

En outre, nous avons construit le Sprite (plus de 200 000 lignes de code nouveau au total) avec une petite équipe qui était en moyenne de seulement environ quatre diplômés, étudiants et un ou deux personnel ou assistants de premier cycle. Nous avons jamais trop grandes pour avoir des réunions de projet dans mon bureau, bien qu’il y avait des fois où nous avons dû emprunter deux chaises supplémentaires pour compléter les six déjà dans mon bureau.

Historique du projet

L’histoire du Sprite se divise grossièrement en trois phases : premiers développement, consolidation et développement de l’EPA et nouvelles entreprises et clôture.

La première phase du Sprite, le développement initial, a duré depuis la Fondation du projet à l’automne 1984 jusque vers la fin de 1987. Nous avons commencé le codage sur stations de travail Sun-2 au début de 1985 et avait un système qui pourrait exécuter des commandes shell en printemps 1986. À l’été 1986 nous avons commencé à développer le système de fichier Sprite « réel » (nous avions utilisé un ancien système de fichier réseau appelé CNBF jusque là). À cette époque, nous avons aussi commencé le processus de migration et le portage du système X window. À l’automne de 1987 toutes ces choses fonctionnaient, ainsi qu’un protocole serveur sur internet. Nous avions porté sous Sprite au soleil-3. À ce stade nous copié sur les sources du noyau de Sprite et a commencé à faire tout notre développement de noyau sur Sprite lui-même.

La deuxième phase dans l’histoire du Sprite dura de fin 1987 à fin des années 1990. Cette phase se composait principalement de la consolidation. Au début de 1988, nous avons fait une révision majeure du système de fichiers. Support de périphérique distant a été amélioré, la mise en œuvre du dispositif de pseudo a été réécrit et un protocole de récupération simple a été présenté afin que le système pourrait récupérer gracieusement de serveur tombe en panne. Processus de migration a subi des améliorations majeures également, et par la fin de 1988, il est devenu assez stable pour nous d’utiliser quotidiennement dans le développement du système. En 1988, nous avons porté Sprite à la recherche de l’ÉPERON multiprocesseur (le projet de l’épi a fourni une grande partie du financement précoce de Sprite), et en 1989, nous avons porté il DECstation-3100 et plates-formes Sun-4. Un port à la machine de symétrie Sequent était carred out à Sequent en fin 1989 et le début des années 1990.

En fin 1988 nous a commencé à soutenir les utilisateurs autres que les développeurs de Sprite. La communauté des utilisateurs grandit en taille, atteignant environ 80 en 1990 et 1991. Nous avons aussi préparé une cassette de distribution afin que nous puissions faire Sprite disponible aux gens en dehors de Berkeley. Les premières bandes ont été envoyés à la fin de 1989 ; pendant la durée du projet Sprite a couru à une dizaine de sites différente. Toutefois, installation de la distribution de Sprite n’a jamais été très facile, et cette limitée d’utilisation du système en dehors de Berkeley.

Le nouveau développement le plus significatif au cours de la deuxième phase du Sprite était la mise en œuvre de l’EPA. Nous fait des avant-projets et études en 1988, mais n’a pas solidifier la conception du prototype jusqu’en 1989 (dans le cadre du projet RAID nouvellement commencé). Codage a commencé fin 1989. Au printemps de 1990 LFS montrait des signes de vie, et son entrée dans l’utilisation de la production à l’automne 1990. En fin 1991, pratiquement tous les dizaines disques du Sprite utilisaient LFS.

La dernière phase du projet a commencé à la fin des années 1990 et a continué jusqu’en 1995. Dans cette phase, nous avons entrepris plusieurs projets, dont la plupart reflète l’importance croissante du projet sur les questions liées à la gestion du stockage. Au cours de l’hiver 1990, nous avons commencé à analyser le comportement de récupération après que fichier serveur tombe en panne ; Cela a conduit à une série d’expériences avec les meilleures techniques de récupération, comme pilotée par le serveur récupération et l’utilisation de stockage non volatile. En 1991, nous avons commencé un projet pour voir si le Sprite pourrait être ré-implémenté comme un processus utilisateur-niveau serveur qui s’exécute sous le noyau Mach 3.0 ; Ce projet complété à l’été 1992 avec fonctionnalité importante mais des performances décevantes. En 1991 et 1992, nous avons également développé le système de bibliothèque de bande Jaquith, qui mis à la disposition des systèmes de bandes contrôlée par robotisé pour Sprite et autres systèmes UNIX. Durant la même période, nous avons commencé à expérimenter avec des fichiers de l’entrelacement entre plusieurs serveurs de fichier (zèbre) et d’appliquer les techniques de l’EPA aux baies de disques (scierie) des projets.

Comme la plupart des logiciels, le noyau du Sprite est devenu plus difficile et plus difficile à maintenir car il vieilli. Révisions fréquentes et des changements dans le personnel affecté au projet a conduit à des augmentations dans la complexité du système, malgré tous nos efforts pour garder les choses simples et propres. En outre, nous l’avons trouvé plus dur et plus dur pour faire face à l’évolution de la situation dans les systèmes d’exploitation commerciaux. En 1990, il y a plusieurs versions commerciales d’UNIX avec des équipes de soutien massif, comme System V, Solaris et OSF. Ces systèmes ont été ajout de fonctionnalités à un rythme rapide et nos utilisateurs souhaité avoir accès à ces fonctionnalités sous Sprite. Nous avons ajouté de nouvelles fonctionnalités telles que les bibliothèques partagées et une compatibilité binaire avec SunOS et Ultrix, mais nous nous sommes retrouvés à dépenser plus et plus de temps sur les tâches qui n’étaient pas orientée vers la recherche.

À la fin de 1991, nous avons décidé de mener le projet de Sprite à une fermeture progressive. Après qu’on n’a pas démarré tout nouveau développement majeur et aucun nouveau étudiants diplômés a rejoint le projet. Nous nous sommes arrêtés à encourager de nouveaux utilisateurs de travailler sur le Sprite, alors la communauté des utilisateurs a diminué lentement revenir à tout l’équipe de Sprite. Sprite avait servi nous long et bien comme un véhicule de recherche ; il était temps de passer à autre chose.

Déceptions

Ma plus grande déception sur le projet de Sprite, c’est que nous n’étions pas en mesure de transférer les technologies Sprite dans l’usage ordinaire. Nous avons fait une distribution libre de Sprite, mais il était difficile d’installer le Sprite de la distribution. En outre, amener les gens à passer à un autre système d’exploitation était difficile : les systèmes Unix commerciaux ajouté des fonctionnalités à un rythme que nous ne pouvions pas correspondre, et il était difficile de maintenir la portabilité des applications. Il y n’avait aucun moyen d’utiliser certaines technologies Sprite (telles que son système de fichiers) sans adopter l’ensemble du système. En conséquence, autres systèmes de fichiers NFS et AFS est devenu employé couramment tandis que Sprite n’a pas.

Certaines des idées Sprite sont peu à peu trouver leur chemin dans l’usage plus large, tels que la migration de processus (popularisé sous la forme de migration des ordinateurs virtuels) et de l’EPA (utilisée dans les produits commerciaux tels que NetApp et systèmes de contrôle pour mémoire flash). Cependant, ces idées devaient être réimplémenté ; Il n’a pas été possible pour d’autres personnes tout simplement prendre le Sprite code et l’utiliser. Peut-être il aurait été mieux si nous avions construit Sprite dans le prolongement d’un système d’exploitation existant, plutôt que de construire un nouveau système d’exploitation à partir de zéro ; ce serait ont simplifié de transfert de technologie. Cependant, il probablement aurait gardé nous d’explorer les aspects système-image unique du système, qui aurait été difficile à mettre en œuvre dans un système existant.

Contributeurs de sprite

Beaucoup de gens ont contribué à Sprite au fil des ans. Je ne peux pas espérer chaque contribution significative de la liste, mais je vais essayer quand même. La liste ci-dessous résume les travaux des membres du projet principal (mes étudiants-chercheurs et le personnel qui relevait directement de moi). Les gens sont répertoriés dans l’ordre chronologique de la date où ils ont commencé à travailler sur les choses liées à Sprite, et les projets sont listés en premier avec les plus importants (à mon avis).

  • Brent Welch (été 1984 – printemps 1990): Les appels de procédure distante ; système de fichiers (gestionnaire de stockage, commutateurs de système de fichier, préfixes, recherche de nom, périphériques distants, protocole de récupération de crash, formatage du disque, dump et restauration, soutien de migration) ; Pseudo-périphériques ; systèmes de fichier Pseudo ; Système de fichiers CNBF ; Prise en charge NFS ; pilotes de périphérique ; noyau profilage ; Bootstrapping.
  • Andrew Cherenson (automne 1984 – automne 1987): Protocole Internet sever ; conception de système de fenêtre et 10 X Portage ; minuterie ; interfaces série ; le débogage au niveau de l’utilisateur ; Pseudo-dispositifs ; processus init ; commande Portage (commandes de réseau, connexion) ; appels liés aux processus système ; Compatibilité UNIX ; saisie manuelle de mise en forme ; Bibliothèque C.
  • Fred Douglis (automne 1984 – automne 1990): Migration de processus et le programme de pmake ; Compatibilité UNIX et le portage de commande ; interfaces d’appel système ; synchronisation, planification et processus en charge ; le portage et le soutien aux grands programmes comme emacs et tex ; manipulation de piège et UART soutien à ÉPERON ; les premiers travaux de conception pour les systèmes de fichiers ; expériences avec des disques optiques.
  • Mike Nelson (automne 1984 – automne 1988): mémoire virtuelle ; système de fichiers (mise en cache, vérificateur de disque, les interactions de vm, soutien de migration, récupération sur incident, sélectionnez) ; noyau de débogage ; Ports Sun-3 et DECstation-3100 ; pilotes de périphérique et de réseau ; traitement du signal ; Port de l’épi (mémoire virtuelle, piège des gestionnaires, etc.) ; Portage de la commande.
  • John Ousterhout (automne 1984 – été 1994): Allocation de mémoire ; Bibliothèque C ; pilote de terminal ; contexte de commutation ; GCC Portage, mkmf programme.
  • Adam de Boor (automne 1986 – été 1988): programme de Pmake ; X 11 Portage (par exemple, les pilotes de périphériques et les code région) ; xman et mkmf programmes ; débogueur de Swat.
  • Mendel Rosenblum (hiver 1988 – automne 1992): Système de fichiers ; Port de l’épi ; outils de débogage ; pilotes de disque ; Port soleil-4 ; Portage de X11R4.
  • Mary Baker (hiver 1988 – automne 1994): Reprise analyse et refonte ; contrôle de congestion pour les appels de procédure distante ; zone de récupération ; Soleil-4, SPARCstation, SPARCstation-2 ports ; mesures de système de fichiers ; analyse des usages de la NVRAM ; RPC permutation d’octets ; Pilote de périphérique SCSI ; conversion de multiprocesseur.
  • Bob Bruce (automne 1988 – automne 1990, 1991 automne – hiver 1992): Démons de spouleur ; dump et restore utilities ; Bande de sprite de distribution ; soutien pour la compilation et les outils de débogage ; niveau utilisateur profilage ; soutien à virgule flottante ; DECstation-3100 et Sequent ports ; Compatibilité UNIX ; Soutien d’opération Desert Storm ; X11r5 port.
  • John Hartman (automne 1988 – automne 1994): Zèbre rayé de système de fichiers ; mesures de système de fichiers ; port de multiprocesseur de l’épi ; mesures de Sprite en cours d’exécution en environnement multiprocesseur épi ; pilotes de périphérique et réseau (FDDI et Ultranet) ; analyse de synchronisation ; outil de vérification de disque, les décharges et autres utilitaires de disque ; prise en charge multiprocesseur ; amorçage ; soutien du débogueur ; Soutien de l’EPA ; planificateur.
  • Don Reeves (printemps 1989): Inverse ARP et.
  • Ken Shirriff (été 1989 – printemps 1995): Transfert de fichiers à grande vitesse à l’aide de RAID ; traces de système de fichiers ; analyse de la mise en cache de nom ; mémoire virtuelle partagée ; fichiers mappés ; Synchronisation de système-V ; application de la sécurité ; support de courrier ; Compatibilité UNIX ; liaison dynamique ; démons du réseau ; Commande DECstation-3100 Portage ; benne basculante/restaurer utilitaires.
  • Mike Kupfer (été 1990 – été 1992): Sprite comme processus de serveur de Mach ; mesures pour le document d’analyse des Sprite ; erreur interne vérifie dans le noyau ; support pour pmake, X, utilitaires benne/restauration et autres outils d’administration.
  • Système d’archivage de Jim Mott-Smith (hiver 1991 – automne 1992): Jaquith bande ; Pilotes SCSI ; Prise en charge NFS ; Internet protocol server prend en charge ; benne basculante/restaurer utilitaires ; soutien de sendmail.
  • Geoff Voelker (automne 1991 – été 1992): Les utilitaires de disque ; Pilote de réseau FDDI ; utilitaires de réseau.
  • Matt Secor (été 1992): Soutien de débogueur.
Outre les personnes énumérées ci-dessus, il y avait beaucoup d’autres qui ont apporté une contribution importante au Sprite, même s’ils n’ont pas rapport directement à moi. Voici quelques-uns des « assistants extérieur » ; Mes excuses à tous ceux que j’ai négligé.

Bob Beck (port Sequent), Ann Chervenak (pilotes de périphériques), Doug Johnson (épi de débogage), Ed Lee (pilote d’entrelacement RAID), Long de Dean (kernel bug fixation, amorçage, SPARCstation port), Ethan Miller (support des contrôleurs RAID), Srinivasan Seshan (support Ultranet), Thorsten Von Eicken (port X11R4), Jay Vosburgh (port Sequent).

Remarque : cette page a été écrit dans les années 1990 ; J’ai redécouvert en février 2011 et mis à jour pour produire cette page.