1 / 7

Enabling BITE: High-Performance Snapshots in a High-Level Cache

Enabling BITE: High-Performance Snapshots in a High-Level Cache. Ross Shaull <rshaull@cs.brandeis.edu> Liuba Shrira <liuba@cs.brandeis.edu> Brandeis University. Presented 2007-10-15 SOSP WiP session 2007. Our Snapshot System. X := Snapshot now.

sara-valenzuela
Télécharger la présentation

Enabling BITE: High-Performance Snapshots in a High-Level Cache

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Enabling BITE:High-Performance Snapshots in a High-Level Cache Ross Shaull <rshaull@cs.brandeis.edu> Liuba Shrira <liuba@cs.brandeis.edu> Brandeis University Presented 2007-10-15 SOSP WiP session 2007

  2. Our Snapshot System X := Snapshot now Applications “time travel” in a past virtualized to look like present. Back-In-Time Execution (BITE) put Application put get Run on snapshot X

  3. But which cache? Our Approach: Cache Integration • Our approach • Virtualized • Crash consistent • Requires Write-Ahead Snapshot invariant P Q P Q snapshot snapshot snapshot P Q P Q R

  4. Best Level Snapshot System • High level • Database, file system • Leverage recovery • Delay writes • Why not lower level? • Difficult to achieve consistent application-requested snapshots • Sync from higher levels at snapshot declaration Application Database File System Volume Manager Controller

  5. Cost of WAS-Invariant • Prototype implemented in Berkeley DB 4.5.20 • 1.8 GB database; snap-1 • Writing due to WAS can be hidden • Uniform: about 1 to 1 (cache: 9994 dirty pages) • Highly skewed (99/1): 35 to 1 • Trickle to avoid slowing down checkpoint • Maintains WAS invariant because trickle before chkpt • Not end of story • Snapshot metadata is transactional • We are analyzing how these costs can be minimized in BDB

  6. Thanks • Sponsors of student scholarships!

  7. Without Cache Integration • On disk • Sync for consistency • Negotiate with application to allow progress to be made while syncing; worst case: quiescence P Q snapshot P Q R P Q snapshot

More Related