1 / 14

Data Persistence for ABLE Extensions

Michael Torchio College of Engineering and Mathematical Sciences University of Vermont Jorge Guerra Raju Rangaswami School of Computing and Information Sciences Florida International University. Data Persistence for ABLE Extensions. Self-Managing storage systems

frankstevens
Download Presentation

Data Persistence for ABLE Extensions

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. Michael Torchio College of Engineering and Mathematical Sciences University of Vermont Jorge Guerra Raju Rangaswami School of Computing and Information Sciences Florida International University Data Persistence for ABLE Extensions

  2. Self-Managing storage systems Use idle or cheaply available computational cycles to add intelligence to storage systems Adapts to high-level system goal specifications Standardized development environment allows versatile self-management extensions ABLE Overview

  3. Problem statement • Systems need to preserve data across reboots, power failures, and program terminations. • Example: history-based optimization of disk use • Data held by programs in volatile memory • Need to store data to disk, allowing updates

  4. Definitions • Memory page – fixed-length block in main memory, 4kB on Linux • Disk page – 4 kB area of hard disk, typical unit of read/write • Update – copy page(s) from memory to disk • Restore – reassemble data in memory from disk copy

  5. Challenges • Need more than pointer to data • Data structures vary greatly in size • Difficult to store, reassign types • Nested structures add complexity • Pointers need modification • Efficiently updating in-place requires data location • Policies for updates must be defined

  6. API of Serializer

  7. Preserve copy of memory

  8. Persistent allocation standard malloc()‏ Serializer User pmalloc()‏ no – add a block space in any block? yes *pointer Disk Manager Storage stack Hard disk

  9. Updates may lead to writes Serializer User pupdate()‏ mark_as_dirty()‏ success? flush? mark_as_clean()‏ Disk Manager translate address; write Storage stack Hard disk

  10. Disk address lookup Mapping of memory page to virtual page Mapping of virtual page to disk page Physical memory address Virtual page address Disk address

  11. Preliminary metrics – with sync()‏ • In every case, the data was changed 1000 times. • With little outside disk usage: • No persistence (control): 1 millisecond • 1 pupdate(): 7 milliseconds • 1000 pupdate(): 1.75 seconds • Under heavy disk write conditions: • No persistence (control): 1 millisecond • 1 pupdate(): 20 milliseconds • 1000 pupdate(): 4.5 seconds • Under heavy disk read conditions: • No persistence (control): 1 millisecond • 1 pupdate(): 1 second • 1000 pupdate(): many minutes

  12. Future Work • Investigation into storage of mapping tables • Adapting the concept to allow allocations > 4k • Restoring from disk still requires the user to list location of each pointer • Further timing tests and optimizations

  13. References • [1] Jorge Guerra et al. The Case for Active Block Layer Extensions. http://www.cs.fiu.edu/~raju/WWW/publications/speed2008/paper.pdf • [2] Troy D. Hanson. TPL Serialization Library. http://tpl.sourceforge.net/ • This research funded by NSF IIS-0552555, “Research Experiences for Undergraduates: Autonomic Computing Research at FIU”

More Related