1 / 26

Semantically-Smart Disk Systems

Semantically-Smart Disk Systems. Muthian Sivathanu, Vijayan Prabhakaran, Florentina Popovici, Tim Denehy, Andrea Arpaci-Dusseau, Remzi Arpaci-Dusseau University of Wisconsin, Madison. The Storage Protocol Stack. A Tale of Two Layers. Two layers: The file system and RAID

rickd
Download Presentation

Semantically-Smart Disk Systems

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. Semantically-Smart Disk Systems Muthian Sivathanu, Vijayan Prabhakaran, Florentina Popovici, Tim Denehy, Andrea Arpaci-Dusseau, Remzi Arpaci-Dusseau University of Wisconsin, Madison

  2. The Storage Protocol Stack

  3. A Tale of Two Layers • Two layers: The file system and RAID • Origins: The hardware/software boundary • S/W: The file system • H/W: The disk • Each increasingly complex • Each a world unto itself • Separated by a narrow interface (SCSI) File System RAID

  4. Your Innovations In Storage:Where In The Stack Should They Go?

  5. Option #1: In The File System • Put innovations in the file system! • Pros: • Lots of semantic information(directories, files, inodes) • Well-defined interfaces (vnode/VFS) • Cons: • No low-level information(head position, RAID scheme) • Hard to deploy: Many FS’s out there • File systems change slowly • FFS [1984] -> ext2 [2002] File System RAID

  6. Option #2: In The RAID • Put innovations in the RAID system! • Pros: • Lots of low-level knowledge • Easy to deploy, sell • Lots of “smarts” (CPUs + Memory) • Cons: • “A stream of block reads + writes,full of bits & bytes, signifying nothing”(no semantic knowledge) File System RAID

  7. The Root Of The Problem: Narrow Interfaces • Narrow interfaces stifle info flow • SCSI to file system: Linear array of blocks • SCSI to disk system:Stream of block reads and writes • Result: Innovation is limited • No “FS-like” innovations in RAID • Anything where info from BOTHsubsystems is required can’t be done File System SCSI RAID

  8. So What’s A Storage-SystemInnovator To Do?

  9. The Ideal Solution? • Exploit raw processing and memory of RAID • Built in low-level knowledge • Easy to deploy • Keep interface the same • Assume traditional file system/RAID boundary • Acquire semantic information of file system • Learn about files, directories, inodes, andother file system data structures

  10. Semantically-Smart Disk System (SDS) • Disk system that understands file system • Data structures • Operations • Operates underneath unmodified FS • Must discover layout + on-disk structures • Must “reverse engineer” block stream • Exploits knowledge and “smarts” to implement new class of services File System SDS CPU $

  11. Outline • Motivation • Semantic Knowledge: Acquisition • Semantic Knowledge: Exploitation • Case studies • Conclusions

  12. Data I-Bitmap D-Bitmap Inodes Data I-Bitmap D-Bitmap Superblk Inodes Static Knowledge: File System Layout • Challenge: How to discover layout information? • White-box approach: Embed knowledge in SDS • Trend: FS layout does not change frequently Group 1 Group 2

  13. Have Knowledge, Will Innovate • Knowing structures is not enough (sometimes) • Data block overloading (data, pointer, directory) • High-level operations not known (create, delete) • Requires new on-line techniques • Direct classification • Indirect classification • Block association • Operation inferencing

  14. I-Bit I-Bit Data D-Bit D-Bit Inode Super Data Inode Direct Classification • Given address, determine type directly • Direct classification via bounds check • Given disk address, can check bounds to determine type(superblock, bitmaps, inodes, general data block)

  15. I-Bit Data I-Bit D-Bit D-Bit Inode Super Data Inode Beyond Simple Meta-Data • Want to cache other meta-data blocks • Directory blocks, indirect-pointer blocks • Problem: Data blocks are overloaded type • Block in “data” region could be: file data, dir, pointer • Direct classification necessary but not sufficient • Indirect classification via inode snooping

  16. SDS Directory Directory Hash Table Type Size Inode Ptr1 Ptr2 Ptr3 Data I-Bit I-Bit D-Bit D-Bit Inode Super Data Inode Indirect Classification: Directories Ptr1 Ptr3 Ptr2

  17. SDS Directory Hash Table Data I-Bit I-Bit D-Bit D-Bit Inode Super Data Inode Indirect Classification In Action Check Hash If Present, Cache Ptr1 Ptr3 Ptr2

  18. Indirect Classification: Issues • Space overhead • Small overhead per directory and indirect block • Time overhead • 1 hash update per pointer, 1 lookup per data block • Tricky: Sometimes data block is seen “early” • Haven’t yet seen pointer associated with data block • Solution #1: OK to misclassify some blocks for some amount of time • Solution #2: Must defer classification until pointer has been observed

  19. Getting Rid Of The Dead • If file blocks are deleted, remove them from cache • No need to keep dead blocks around • Problem: How to determine if a file is deleted? • Need to look for signs of deletion • Three different places to look: • Inode bitmaps • Directory that contains file • Inode itself • Operation inferencing via block differencing

  20. SDS = I-Bitmap Read Old Version Data I-Bit I-Bit D-Bit D-Bit Inode Super Data Inode Operation Inferencing: Detecting Deletes (Inode Bitmap) Diff Result:Deleted Files

  21. Operation Inferencing: Overheads • Space overhead • Block cache of inodes, indirect pointers, bitmaps, etc.(could be substantial) • Time overhead • CPU: Difference operation is like an extra copy • Disk: May require block read (if small/no cache) • [In paper: Quantified time and space overheads] • Main point: There is a CPU and memory cost

  22. Using Semantic Knowledge • Fast RAID Reconstruction • Only copy “live” data to hot-spare • Track-aligned Extents [Schindler et. al. ‘02] • Placing files in disk cognizant manner • Journaling [Hagmann ‘87] • Limit study: can implement complex “FS”-likefunctionality within a semantically-smart disk • File-aware Caching • Caching meta-data under BSD FFS • Caching journal under Linux ext3

  23. Conclusions

  24. Conclusions • Innovation in traditional storage stack is limited • File system: high but not low-level info • Storage system: low but not high-level info • Semantically-smart disks: Best of both worlds? • Takes advantage of “smart” disk systems • Exploit low-level information… • …with high-level knowledge of file system • A remaining challenge • Overcoming the “file system obfuscation” problem

  25. “To know that we know what we know, • and that we do not know what we do not know, • that is true knowledge.” • Confucius • http://www.cs.wisc.edu/wind

  26. “A man cannot inquire about what he knows, • because he knows it, • and in that case he is in no need of inquiry, • nor again can he inquire about • what he does not know, • since he does not know what he is to inquire.” • Socrates

More Related