Time travel in the virtualized past: cheap fares and first class seats Liuba Shrira Brandeis University liuba@cs.brandeis.edu Catharine van Ingen Microsoft vaningen@microsoft.com Ross Shaull Brandeis University rshaull@cs.brandeis.edu 1 Abstract “Time travel” in the storage system is accessing past stor- age system states. Legacy application programs could run transparently over the past states if the past states were vir- tualized in a form that makes them look like the current state. There are many levels in the storage system at which past state virtualization could occur. How do we choose? We think that past state virtualization should occur at a high storage system buffer manager level, such as database buffer manager. Everything above this level can run legacy programs. The system below can manage the mechanisms needed to implement the virtualization. This approach can be applied to any kind of storage system, ranging from tra- ditional databases and file systems to the new generation of specialized storage managers such as Bigtable. Granted that time travel is a desirable feature, this position paper considers the design axis for virtualizing past states for time travel, and asks what amounts to the question, can we sit in first class and still have cheap fares? 2 Virtualized past states Cheap disk means a storage system can retain past applica- tion states and keep them around for a long time. Back-in- time execution (BITE) is the ability of the storage system to run read-only application programs on snapshots of the past storage system states in addition to the current state. BITE provides what is popularly called time travel. Traditionally snapshots have been used to run queries over past states (snapshot isolation [1] queries) to avoid interfering with rapidly evolving current state, and for rapid light weight re- covery by copy-paste or query, particulary to cope with in- advertent user errors. BITE in addition allows to audit and mine persistent past states in real-time, performing after- the-fact analysis of past states, possibly using methods that were unavailable at the time. Such abilities are increasingly demanded by modern applications. We want to be able to provide BITE in storage sys- tems which support legacy applications. Therefore we want to virtualize the snapshots of the past states in a form that looks like the current state so that (unmodified) programs that run on the current state can run on snapshots. This ap- proach is in contrast, to temporal databases that introduce an explicit time coordinate, virtualizing the current state to look like the past state. Figure 1 depicts how an unmodified application pro- gram issueing get and put operations to the storage system, Application (1) Application runs on current state put get Application X := Snapshot now (2) Application declares snapshot X put get Application put X := Snapshot now (3) An update after snapshot X Application Run on snapshot X get (4) Application runs on snapshot X Applications “time travel” in a past virtualized to look like present. Back-In-Time Execution (BITE) Fig. 1: Snapshot interface interacts with snapshots. First, in (1) the get and put opera- tions access the current state, (2) snapshot X is declared, (3) snapshot system retains the state of an object, before a put operation modifies the object first time following snapshot X declaration, (4) application now runs on snapshot X, get operation observes the object state retained for snapshot X. Legacy applications expect to see a consistent state of a storage system. To this end, our virtualized past states will provide crash consistency. Crash consistency corresponds to the state the application might see if the storage system