140 likes | 259 Views
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
E N D
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 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
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
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
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
Persistent allocation standard malloc() Serializer User pmalloc() no – add a block space in any block? yes *pointer Disk Manager Storage stack Hard disk
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
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
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
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
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”