A Brief Retrospective on the Sprite Network Operating System

Recorded: Sept. 13, 2026, 5:09 p.m.

Original

Summarized

sprite/sprite.txt at master · OSPreservProject/sprite · GitHub

Navigation MenuSign inAppearance settingsPlatformAI CODE CREATIONGitHub CopilotWrite better code with AIGitHub Copilot appDirect agents from issue to mergeMCP RegistryIntegrate external toolsDEVELOPER WORKFLOWSActionsAutomate any workflowCodespacesInstant dev environmentsIssuesPlan and track workCode ReviewManage code changesCode QualityEnforce quality at mergeAPPLICATION SECURITYGitHub Advanced SecurityFind and fix vulnerabilitiesCode securitySecure your code as you buildSecret protectionStop leaks before they startEXPLOREWhy GitHubDocumentationBlogChangelogMarketplaceView all featuresSolutionsBY COMPANY SIZEEnterprisesSmall and medium teamsStartupsNonprofitsBY USE CASEApp ModernizationDevSecOpsDevOpsCI/CDView all use casesBY INDUSTRYHealthcareFinancial servicesManufacturingGovernmentView all industriesView all solutionsResourcesEXPLORE BY TOPICAISoftware DevelopmentDevOpsSecurityView all topicsEXPLORE BY TYPECustomer storiesEvents & webinarsEbooks & reportsBusiness insightsGitHub SkillsSUPPORT & SERVICESDocumentationCustomer supportCommunity forumTrust centerPartnersView all resourcesOpen SourceCOMMUNITYGitHub SponsorsFund open source developersPROGRAMSSecurity LabMaintainer CommunityGitHub StarsArchive ProgramREPOSITORIESTopicsTrendingCollectionsEnterpriseENTERPRISE SOLUTIONSEnterprise platformAI-powered developer platformAVAILABLE ADD-ONSGitHub Advanced SecurityEnterprise-grade security featuresCopilot for BusinessEnterprise-grade AI featuresPremium SupportEnterprise-grade 24/7 supportPricingSearch/Sign inSign upAppearance settings

You signed in with another tab or window. Reload to refresh your session.
You signed out in another tab or window. Reload to refresh your session.
You switched accounts on another tab or window. Reload to refresh your session.

Dismiss alert

Uh oh!

There was an error while loading. Please reload this page.

OSPreservProject

/

sprite

Public

Notifications
You must be signed in to change notification settings

Fork
14

Star
57

Code

Issues
0

Pull requests
0

Actions

Projects

Wiki

Security and quality
0

Insights

Additional navigation options

Code

Issues

Pull requests

Actions

Projects

Wiki

Security and quality

Insights

FilesExpand file treemasterBreadcrumbssprite/sprite.txtCopy pathBlameMore file actionsBlameMore file actions Latest commit HistoryHistoryHistory300 lines (261 loc) · 16.5 KBmasterBreadcrumbssprite/sprite.txtCopy pathTopFile metadata and controlsCodeBlame300 lines (261 loc) · 16.5 KBRawCopy raw fileDownload raw fileOpen symbols panelEdit and raw actions123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300A Brief Retrospective on the Sprite Network Operating System------------------------------------------------------------
John OusterhoutComputer Science DivisionDepartment of EECSUniversity of California at Berkeley
Sprite is a research operating system whose development I have had thepleasure of leading over the last eight years. Four graduate studentsand I started the project in the Fall of 1984 because we felt thatcurrent operating systems were paying insufficient attention to local-areanetworks. It seemed to us that networking support had been added in aquick and dirty fashion to systems that were designed to run stand-alone.As a result, networked workstations didn't work well together. At thetime we started Sprite there were no good network file systems (even NFSdidn't exist yet) and administering a network of workstations was anightmare.
Our goal for Sprite was to "do networking right" by building a new operatingsystem kernel from scratch and designing the network support into the systemfrom the start. We hoped to create a system where a collection ofnetworked workstations would behave like a single system with both storageand processing power shared uniformly among the workstations. We hopedthat users would be able to tap the power of the entire network whilepreserving the simple behavior and administrative ease of a traditionaltime-shared system.
I think that we achieved these goals. Four technical accomplishmentsstand out in my mind. First and foremost is Sprite's network file system,which demonstrated that network file systems can provide a convenientuser model without sacrificing performance. Sprite's file system allowsfile sharing while completely hiding the network. It provides the samebehavior among workstations that users would see if they all ran on atraditional time-sharing system. Even I/O devices can be accessedunformly across the network, and user processes can extend the filesystem by implementing its I/O and naming protocols using pseudo devicesand pseudo file systems. At the same time, Sprite uses aggressive filecaching to achieve high performance. Five years after its construction,Sprite still has the fastest network file system in existence.
Sprite's second key accomplishment is its process migration mechanism,which allows processes to be moved transparently between workstationsat any time. With process migration a single user can harness the powerof many workstations simultaneously, achieving speedups of four or moreon common system tasks such as recompilation. The migration mechanismkeeps track of idle machines, uses them for migration, and evictsmigrated processes when a workstation's owner returns, so that migrationdoesn't impact the response time of active users. Evicted processes areremigrated to a different idle machine or executed on their home machine.Sprite is one of only a few systems where process migration has beenused on a day-to-day basis by a large user community.
Sprite's third key accomplishment is its single system image. The filesystem and process migration provide the most obvious evidence of thesingle system image, since they make storage and processing power sharableamong workstations. But in many other ways Sprite looks and feels just likea single system. There is one root partition, one password file, one swaparea (in the network file system), one login database, and so on. The"finger" command tells about all users on all workstations in the Spritecluster, not just those on the workstation where the command was invoked.System administration is no harder with fifty machines in the network thanit is with ten, and adding a new machine is no more difficult than addinga new user account.
Sprite's single system image also supports different machine architecturesin the same cluster. We developed a framework for separating architecture-independent information from architecture-specific information. All theinformation for all architectures is visible at all times, which simplifiescross-development, yet each machine uses the appropriate architecture-dependent information when it is needed.
Sprite's fourth key accomplishment is its log-structured file system (LFS),which demonstrates a radical new approach to file system design. LFStreats the disk more like a tape, writing information sequentially in largeruns that permit great efficiency. We developed a new garbage collectionmechanism that continually opens up large extents of free space on thedisk. The result is a system that writes small files to disk an order ofmagnitude faster than any other existing file system. At the same timeit handles other operations, such as reads and large writes, at leastas well as other systems. Log-structured file systems have many otheradvantages as well, such as fast crash recovery, the ability to storeinformation on disk in compressed form, and the ability to vary the blocksize from file to file.
In addition to the above results, which have already been achieved, thereare several promising projects still underway, such as recovery enhancements,a new file system called Zebra that stripes files across multiple servers,and high-bandwidth file service using disk arrays. Before the Sprite projectends I expect to see major results from each of these projects too.
Throughout the Sprite project we have tried to characterize the behaviorof the system and to use this information to guide future developments.Some of our most important results are the measurements we have made. Thefounding of the project was based in part on file system measurements madeon time-shared systems in 1984 and 1985. We made additional measurementsof Sprite usage in 1991 to see how patterns had changed and to analyzethe potential application of non-volatile memory in networked systems.
Perhaps the most significant accomplishment of all is that we were ableto make the system work, not just for ourselves but for a community ofusers that numbered as high as 80 or more at the peak of the project.Many of these users depended on Sprite for all of their day-to-daycomputing needs, such as mail and printing. For a period of severalyears it was common to see 25-35 simultaneous logins of which only ahalf-dozen were Sprite developers. I know of only one other universityproject that developed a new operating system kernel from scratch andused it to support a user community this large for this long; that projectwas Multics, which was carried out at MIT in the late 1960's.
Furthermore, we built Sprite (more than 200,000 lines of new code in all)with a small team that averaged only about four graduate students and oneor two staff or undergraduate assistants. We never got too large to haveproject meetings in my office, although there were times when we had toborrow two additional chairs to supplement the six already in my office.
The history of Sprite divides into roughly three phases: initialdevelopment, consolidation and LFS development, and new venturesand closeout.
The first phase of Sprite, initial development, lasted from the foundingof the project in the fall of 1984 until about the end of 1987. We begancoding on Sun-2 workstations in early 1985 and had a system that couldexecute shell commands by the spring of 1986. In the summer of 1986 westarted developing the "real" Sprite file system (we'd used an oldernetwork file system called BNFS up until that point). About that timewe also started on process migration and porting the X window system.By the fall of 1987 all of these things were working, along with aninternet protocol sever. We had also ported Sprite to Sun-3's. At thispoint we copied the kernel sources over to Sprite and began doing all ofour kernel development on Sprite itself.
The second phase in Sprite's history lasted from late 1987 to late 1990.This phase consisted mostly of consolidation. In early 1988 we made amajor revision of the file system. Remote device support was improved,the pseudo device implementation was rewritten, and a simple recoveryprotocol was introduced so the system could recover gracefully fromserver crashes. Process migration underwent major improvements also,and by late 1988 it became stable enough for us to use it daily in systemdevelopment. In 1988 we ported Sprite to the SPUR research multiprocessor(the SPUR project provided much of the early funding for Sprite), andin 1989 we ported it to DECstation-3100 and Sun-4 platforms. A port tothe Sequent Symmetry machine was carred out at Sequent in late 1989 andearly 1990.
In late 1988 we began to support users other than Sprite developers. Theuser community gradually grew in size, peaking at around 80 in 1990 and1991. We also prepared a distribution tape so that we could make Spriteavailable to people outside Berkeley. The first tapes were sent out inlate 1989; over the life of the project Sprite has run at about tendifferent sites.
The most significant new development during Sprite's second phase wasthe LFS implementation. We made preliminary designs and studies in 1988but didn't solidify the prototype design until 1989 (as part of thenewly started RAID project). Coding started in late 1989. By the spring of1990 LFS was showing signs of life, and it entered production use in thefall of 1990. By late 1991 virtually all of Sprite's dozen disks wereusing LFS.
The final phase of the project started in late 1990 and will continueuntil Sprite shuts down in late 1993 or early 1994. In this phase weinitiated several new projects, most of which reflected the increasingfocus of the project on issues related to storage management. In thewinter of 1990 we began to analyze the behavior of recovery after fileserver crashes; this led to a series of experiments with better recoverytechniques, such as server-driven recovery and the use of non-volatilestorage. In 1991 we began a project to see if Sprite could bere-implemented as a user-level server process running under the Mach 3.0kernel; this project completed in the summer of 1992 with substantialfunctionality but disappointing performance. In 1991 and 1992 we alsodeveloped the Jaquith tape library system, which made robotically-controlledtape systems available for both Sprite and other UNIX systems. During thesame period we started projects to experiment with striping files acrossmultiple file servers (Zebra) and to improve the bandwidth of remoteaccesses to disk arrays. Both of these projects are still underway.
Like most software, the Sprite kernel became harder and harder to maintainas it aged. Frequent revisions and changes in project personnel led toincreases in system complexity, in spite of our best efforts to keepthings clean and simple. In addition, we found it harder and harder tokeep up with developments in commercial operating systems. By 1990there were several commercial versions of UNIX with massive support teams,such as System V, Solaris, and OSF. These systems were adding featuresat a rapid pace and our users wanted access to these features underSprite. We added new features such as shared libraries and binarycompatibility with SunOS and Ultrix, but we found ourselves spendingmore and more time on tasks that were not research oriented.
At the end of 1991 we decided to bring the Sprite project to a gradualclose. Since then we have not started any major new developments andno new graduate students have joined the project. We plan to completethe projects that are currently underway and then shut down the systemin late 1993 or early 1994. We no longer encourage new users to work onSprite, and our user community is slowly shrinking back to just the Spriteteam. Sprite has served us long and well as a research vehicle; now it istime to move on to other things.
Many people have contributed to Sprite over the years. I can't possiblyhope to list every significant contribution, but I'll try anyway. Thelist below summarizes the work of the principal project members (myresearch students and the staff who reported directly to me). The peopleare listed in chronological order by the date when they started workingon Sprite-related things, and the projects are listed with the mostimportant ones (in my opinion) first.
Brent Welch (Summer 1984 - Spring 1990): Remote procedure calls; file system (storage manager, file system switches, prefixes, name lookup, remote devices, crash recovery protocol, disk formatting, dump and restore, migration support); pseudo devices; pseudo file systems; BNFS file system; NFS support; device drivers; kernel profiling; bootstrapping.
Andrew Cherenson (Fall 1984 - Fall 1987): Internet protocol sever; window system design and X10 porting; timer; serial interfaces; user-level debugging; pseudo-devices; init process; command porting (network commands, login); process-related system calls; UNIX compatibility; manual entry formatting; C library.
Fred Douglis (Fall 1984 - Fall 1990): Process migration and the pmake program; UNIX compatibility and command porting; system call interfaces; synchronization, scheduling, and process support; porting and support for major programs such as emacs and tex; trap handling and UART support for SPUR; early design work for log-structured file systems; experiments with optical disks.
Mike Nelson (Fall 1984 - Fall 1988): Virtual memory; file system (caching, disk checker, vm interactions, migration support, crash recovery, select); kernel debugging; Sun-3 and DECstation-3100 ports; device and network drivers; signal handling; SPUR port (virtual memory, trap handlers, etc.); command porting.
John Ousterhout (Fall 1984 - ??): Memory allocation; C library; terminal driver; context switching; gcc porting, mkmf program.
Adam de Boor (Fall 1986 - Summer 1988): Pmake program; X11 porting (e.g. device drivers and region code); xman and mkmf programs; swat debugger.
Mendel Rosenblum (Winter 1988 - Fall 1992): Log-structured file system; SPUR port; debugging tools; disk drivers; Sun-4 port; X11R4 porting.
Mary Baker (Winter 1988 - ??): Recovery analysis and redesign; congestion control for remote procedure calls; recovery box; Sun-4, SPARCstation, SPARCstation-2 ports; file system measurements; analysis of NVRAM uses; RPC byte-swapping; SCSI device driver; multi-processor conversion.
Bob Bruce (Fall 1988 - Fall 1990, Fall 1991 - Winter 1992): Spooler daemons; dump and restore utilities; Sprite distribution tape; support for compilation and debugging tools; user-level profiling; floating-point support; DECstation-3100 and Sequent ports; UNIX compatibility; Operation Desert Storm support; X11R5 port.
John Hartman (Fall 1988 - ??): Zebra striped file system; file system measurements; port to SPUR multiprocessor; measurements of Sprite running on SPUR multiprocessor; device and network drivers (FDDI and Ultranet); synchronization analysis; disk checker, dumps, and other disk utilities; multiprocessor support; bootstrapping; debugger support; LFS support; scheduler.
Don Reeves (Spring 1989): ARP and reverse ARP.
Ken Shirriff (Summer 1989 - ??): High-speed file transfer using RAID; file system traces; analysis of name caching; shared virtual memory; mapped files; System-V synchronization; security enforcement; mail support; UNIX compatibility; dynamic linking; network daemons; DECstation-3100 command porting; dump/restore utilities.
Mike Kupfer (Summer 1990 - Summer 1992): Sprite as Mach server process; measurements for Sprite analysis paper; internal error checks in kernel; support for pmake, X, dump/restore utilities, and other administrative tools.
Jim Mott-Smith (Winter 1991 - Fall 1992): Jaquith tape archive system; SCSI drivers; NFS support; internet protocol server support; dump/restore utilities; sendmail support.
Geoff Voelker (Fall 1991 - Summer 1992): Disk utilities; FDDI network driver; network utilities.
Matt Secor (Summer 1992): Debugger support.
In addition to the people listed above, there were many others who madesignificant contributions to Sprite even though they didn't reportdirectly to me. Here are a few of the "outside helpers"; apologies toanyone that I've overlooked.
Bob Beck (Sequent port), Ann Chervenak (device drivers), Doug Johnson(SPUR debugging), Ed Lee (RAID striping driver), Dean Long (kernel bugfixing, bootstrapping, SPARCstation port), Ethan Miller (RAID controllersupport) , Srinivasan Seshan (Ultranet support), Thorsten Von Eicken(X11R4 port), Jay Vosburgh (Sequent port).

Footer

Footer navigation

Terms

Privacy

Security

Status

Community

Docs

Contact

Manage cookies

Do not share my personal information

You can’t perform that action at this time.

The Sprite project was initiated by John Ousterhout and a team of graduate students in 1984 with the objective of fundamentally rethinking operating system design to better support local area networks. The core motivation was that existing operating systems inadequately addressed networking, leading to poor interoperability among networked workstations. The goal of Sprite was to address this by building a new operating system kernel from the ground up, designing network support directly into the system architecture from the beginning. The vision was to create a system where multiple networked workstations could function as a single system, uniformly sharing processing power and storage, while retaining the intuitive simplicity and ease of administration characteristic of traditional time-shared systems.

The project yielded several significant technical accomplishments. First, Sprite developed a network file system that successfully facilitated file sharing while completely abstracting the underlying network from the user. This system ensured that workstations exhibited consistent behavior, similar to those running on a traditional time-sharing system, while enabling uniform access to I/O devices across the network. This was achieved through aggressive file caching, which resulted in a network file system that remained the fastest of its kind even five years after its construction. Second, the system incorporated a process migration mechanism that allowed processes to be moved transparently between workstations. This capability enabled a single user to harness the resources of multiple machines simultaneously, achieving speedups in common tasks. The migration mechanism managed idle machines for migration and ensured that active user response times were not negatively impacted by the process movement. Furthermore, the integration of the file system and process migration provided tangible evidence of a single system image, as the storage and processing capabilities were made shareable among all workstations. This unified view was also reflected in simplified system administration, where commands could report status across the entire cluster, and the system supported multiple machine architectures by separating architecture-independent information from architecture-specific details. Finally, Sprite introduced a log-structured file system (LFS), which represented a radical departure from traditional file system design by treating the disk more like sequential tape storage. LFS employed a novel garbage collection mechanism that continuously freed up large extents of free space, enabling small file writing to disk at a speed order of magnitude faster than existing file systems, while also providing faster crash recovery and support for compressed data storage.

The development of Sprite evolved through distinct phases. The initial phase, spanning from 1984 to late 1987, focused on foundational development, including the network file system, process migration, and the porting of the X window system, alongside establishing an internet protocol server. The second phase, from late 1987 to late 1990, was dedicated to consolidation, involving major revisions to the file system, improvements to remote device support and recovery protocols, further enhancements to process migration, and the implementation of LFS. During this period, the user community grew to around eighty, and distribution tapes were prepared to make Sprite available to external users. The final phase began in late 1990 and continued until the system's eventual shutdown in late 1993 or early 1994, focusing on advanced storage management, including experiments with server-driven recovery and exploring file system striping technologies.

The project benefited from extensive contributions from numerous individuals, including Brent Welch, Andrew Cherenson, Fred Douglis, Mike Nelson, and many others whose work covered areas such as remote procedure calls, kernel programming, file system design, device drivers, and synchronization protocols. This collaborative effort, involving a small team of graduate students and staff, allowed for the realization of these complex innovations. Ultimately, Sprite demonstrated a strong capacity to serve a large user community and provided a robust framework for exploring forward-thinking approaches to operating system design.