VINO: An Integrated Platform for Operating System and Database Research The Harvard community has made this article openly available. Please share how this access benefits you. Your story matters Citation Small, Christopher and Margo Seltzer. 1994. VINO: An Integrated Platform for Operating System and Database Research. Harvard Computer Science Group Technical Report TR-30-94. Citable link http://nrs.harvard.edu/urn-3:HUL.InstRepos:26506446 Terms of Use This article was downloaded from Harvard University’s DASH repository, and is made available under the terms and conditions applicable to Other Posted Material, as set forth at http:// nrs.harvard.edu/urn-3:HUL.InstRepos:dash.current.terms-of- use#LAA VINO An Integrated Platform for Op erating System and Database Research Christopher Small and Margo Seltzer Harvard University Cambridge MA fchrismargogdasharvardedu Harvard Computer Science Laboratory Technical Report TR of buer p o ol management le storage pro cess schedul Abstract ing and concurrency control In Stonebraker wrote For example the disk buer cache management strat egy most commonly used by op erating systems is LRU Op erating system services in many existing sys this is sub optimal for most relational database disk access tems are either to o slow or inappropriate Cur patterns CHOU rent DBMSs usually provide their own and make DBMS have usually dealt with the architectural mis little or no use of those oered by the op erating match by evasion they overcome op erating system limita system STON tions by reimplementing and avoiding the use of op erating system services wherever p ossible The standard op erating system mo del has changed lit For example rather than use the supplied lesystem tle since that time and we b elieve that at its core it is a DBMS will write directly to the raw disk partition the wrong mo del for DBMS and other resourceintensive ORA SYB The layout of the data on the partition applications The standard mo del is inexible unco op er and the caching of that data then falls under the con ative and irregular in its treatment of resources trol of the DBMS However b ecause the virtual memory We describ e the design of a new system the VINO ker of the database pro cess is still managed by the op erat nel which addresses the limitations of standard op erating ing system inmemory copies of disk buers are double systems It fo cuses on three key ideas buered they are stored by the DBMS in memory or on the database partition and also by the op erating sys Applications direct p olicy tem in the backing store for pro cess In addition stan Kernel mechanisms are reusable by applications dard op erating systems to ols eg to ols that display the contents of a directory can not b e used From the op All resources share a common extensible interface erating system p ersp ective this is akin to the manage ment of BLOBs in relational databases a BLOB is VINOs p ower and exibility make it an ideal platform for stored by the DBMS but is not a rstclass entity that the design and implementation of traditional and mo dern can b e manipulated using the standard DBMS interface database management systems Furthermore the allo cation b etween the lesystem and the DBMS is completely static the device containing the lesystem must b e taken oline and rebuilt in order to Introduction change the size of a partition In general op erating systems are designed for the least Transaction supp ort is rarely provided by general common denominator application This has proven to b e purp ose op erating systems its availability at the user a p o or match for resourceintensive applications such as level is the exception rather than the rule eg Quick database management systems The result is that DBMS silver HASK Instead op erating systems implement avoid using op erating system services and reimplement one or more sp ecial purp ose mechanisms to supp ort re them from scratch covery For example most systems supp ort some type Stonebraker p oints out several ways in which the sp e of le system recovery service but this service is rarely cic requirements of relational databases are p o orly served exp orted to the user level meaning that a DBMS must by traditional op erating system architectures in the areas implement its own recovery system Recovery co de is no plementation or indexing structures The query pro cessor toriously complex and is often the subsystem resp onsible may take advantage of known strengths or weaknesses of for the largest number of system failures SULL Sup various indexing metho ds but it accesses the underlying p orting multiple recovery paradigms is likely to reduce relations through a simple tupleoriented interface using total system robustness calls to retrieve tuples by key scan sequentially through Ob ject databases are presented with greater barriers to a relation or mo dify sp ecic tuples It is this abstract in development and p erformance Ob ject stores that handle terface that we use as the foundation for VINOs resource ob ject faulting through the use of virtual memory man interface The system can take advantage of information agement hardware supp ort eg LAMB are faced ab out the underlying representation but can function cor with the p erformance impact of a protection fault on rst rectly at the abstract level access and if the rst fault was on a read access a second The Illustra DBMS ILLU is a successor to the on write access An ob ject database management system POSTGRES system developed at the University of Cali that is implemented using a clientserver architecture can fornia Berkeley STON It can b e extended by adding end up triplepaging on the server data is present in b oth userwritten co de to implement new data types This co de the database and the servers swap le and on the client can b e run in either the client pro cess or the server pro it is present b oth in the client cache or the client swap cess if it is installed in the server there is no guarantee le that it will not corrupt the server or violate system secu At times a service provided by the op erating system is rity frustratingly close to what is needed by a DBMS For ex The Thor system developed at MIT LISK also al ample Skarra examined the feasability of using standard lows the server to b e extended by adding client co de To Posix lo cking services in a DBMS SKAR She found ensure that client co de do es not compromise the server that there were several places where commercially avail extensions must b e written in a system sp ecic typesafe able implementations did not correctly detect deadlo ck language Theta MYERS that starvation of write lo ck requests can o ccur that the semantics of lo ck upgrades is not consistent across dier Op erating System Perspective ent implementations and that p erformance is inadequate for DBMS use Extensibility The fundamental problem is that the services provided Mach Newer op erating systems have adopted the by the OS are not the services desired or needed by the microkernel architecture ACET which allows the DBMS system to b e extended by adding userlevel servers We next discuss related work and then the motiva to which the kernel can delegate resp onsibility Sys tion for VINO In section we describ e the system ar tem services such as lesystem management can chitecture In section we describ e sp ecic VINO sub b e delegated to external servers A new server can systems that are of use to a DBMS implementor We b e added that has the same interface as an existing conclude with sketches of VINObased implementations of one but with an entirely dierent implementation relational ob jectrelational and ob jectoriented DBMS A database management system can provide a new lesystem server that can b e manipulated using ex isting system to ols but is implemented in a manner Related Work more appropriate for the DBMS use DBMS and op erating systems have confronted the prob The Camelot distributed transaction pro cessing sys lems that VINO addresses Some DBMS implement a tem EPPI takes advantage of this architecture unied resource interface and extensibility some op erat and provides a set of Mach pro cesses to supp ort ing systems also oer limited application control of p olicy nested transaction management lo cking recoverable storage allo cation and system conguration Most of the mechanisms required to supp ort transaction Database Perspective semantics are implemented at user level The result Relational database management systems separate the ing system can b e used by any application not just abstract interface for a tuple from its representation nor clients of a Camelot data manager mally as an element in a Btree or hash table This data indep endence allows highlevel to ols such as query pro Mach VM The Mach virtual memory management cessors to work indep endent of the implementation the system can delegate b oth storage and replacement internal level in ANSISPARC terminology DION p olicy decisions to userlevel servers In the Mach vir In a relational system queries are expressed in terms tual memory management system RASH mem of tuples and keys without regard for the underlying im ory objects are asso ciated with a pager The pager needed a nonblo cking write allows an application to is resp onsible for implementing the backing store for queue a write request and continue to make progress virtual memory while the write takes place SOLA The initial pager design did not allow pagers to con trol eviction p olicy McNamee and Armstrong ex There are disadvantages to b oth techniques When tended the