enabling bite: high-performance snapshots in a high-level cache
DESCRIPTION
Enabling BITE: High-Performance Snapshots in a High-Level Cache. Ross Shaull Liuba Shrira Brandeis University. Presented 2007-10-15 SOSP WiP session 2007. Our Snapshot System. X := Snapshot now. - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: Enabling BITE: High-Performance Snapshots in a High-Level Cache](https://reader035.vdocuments.us/reader035/viewer/2022071807/56812fe6550346895d955c29/html5/thumbnails/1.jpg)
Enabling BITE:High-Performance Snapshots
in a High-Level Cache
Ross Shaull <[email protected]>
Liuba Shrira <[email protected]>
Brandeis University
Presented 2007-10-15 SOSP WiP session 2007
![Page 2: Enabling BITE: High-Performance Snapshots in a High-Level Cache](https://reader035.vdocuments.us/reader035/viewer/2022071807/56812fe6550346895d955c29/html5/thumbnails/2.jpg)
Application
put
put
X := Snapshot now
Run on snapshot X
get
Our Snapshot System
Applications “time travel” in a past virtualized
to look like present.
Back-In-Time Execution
(BITE)
![Page 3: Enabling BITE: High-Performance Snapshots in a High-Level Cache](https://reader035.vdocuments.us/reader035/viewer/2022071807/56812fe6550346895d955c29/html5/thumbnails/3.jpg)
R
But which cache?
Our Approach: Cache Integration
• Our approach– Virtualized– Crash consistent– Requires Write-Ahead Snapshot invariant
snapshot
P Q
P Q
P Q P Q
snapshotsnapshot
![Page 4: Enabling BITE: High-Performance Snapshots in a High-Level Cache](https://reader035.vdocuments.us/reader035/viewer/2022071807/56812fe6550346895d955c29/html5/thumbnails/4.jpg)
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
File System
Database
Volume Manager
Application
Controller
![Page 5: Enabling BITE: High-Performance Snapshots in a High-Level Cache](https://reader035.vdocuments.us/reader035/viewer/2022071807/56812fe6550346895d955c29/html5/thumbnails/5.jpg)
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
![Page 6: Enabling BITE: High-Performance Snapshots in a High-Level Cache](https://reader035.vdocuments.us/reader035/viewer/2022071807/56812fe6550346895d955c29/html5/thumbnails/6.jpg)
Thanks
• Sponsors of student scholarships!
![Page 7: Enabling BITE: High-Performance Snapshots in a High-Level Cache](https://reader035.vdocuments.us/reader035/viewer/2022071807/56812fe6550346895d955c29/html5/thumbnails/7.jpg)
R
Without Cache Integration
• On disk– Sync for consistency– Negotiate with application to
allow progress to be made while syncing; worst case: quiescence
P Q
snapshotQP QP
snapshot