Presentation is loading. Please wait.

Presentation is loading. Please wait.

Department of Computer Sciences, University of Wisconsin Madison DADA – Dynamic Allocation of Disk Area Jayaram Bobba Vivek Shrivastava.

Published byJodie Tate Modified over 8 years ago

Similar presentations

Presentation on theme: "Department of Computer Sciences, University of Wisconsin Madison DADA – Dynamic Allocation of Disk Area Jayaram Bobba Vivek Shrivastava."— Presentation transcript:

1 Department of Computer Sciences, University of Wisconsin Madison DADA – Dynamic Allocation of Disk Area Jayaram Bobba Vivek Shrivastava

2 Department of Computer Sciences, University of Wisconsin Madison Outline Introduction Existing Framework Implementation Issues Results Conclusions

3 Department of Computer Sciences, University of Wisconsin Madison Problem Disk Volumes Allocate physical space on creation Multiple Disk Volumes on a physical disk Unused space Disk space not a premium What If?

4 Department of Computer Sciences, University of Wisconsin Madison Motivation Virtual Machine Environment Add Some points Storage Area Networks Storage area is the bo Dynamic Physical Allocation (LFS style)

5 Department of Computer Sciences, University of Wisconsin Madison Related Work HP AutoRAID Dynamically change redundancy levels Hot Data – Mirrored Cold Data – RAID 5 Dynamic migration of data

6 Department of Computer Sciences, University of Wisconsin Madison Outline Introduction Existing Framework Implementation Issues Results Conclusions

7 Department of Computer Sciences, University of Wisconsin Madison Existing Framework Logical Volume Manager (LVM) User space tool that enables creation of logical volumes of a logical partition. Supports resizing of volumes. Device Mapper (DM) Kernel driver that provides a level of indirection in address translation

8 Department of Computer Sciences, University of Wisconsin Madison LVM design Volume Group (VG) Physical Volume (PV) Logical Volume (LV) Physical Extent (PE) Logical Extent (LE)

9 Department of Computer Sciences, University of Wisconsin Madison LVM design Physical Device

10 Department of Computer Sciences, University of Wisconsin Madison LVM design PV PE

11 Department of Computer Sciences, University of Wisconsin Madison LVM design PV PE

12 Department of Computer Sciences, University of Wisconsin Madison LVM design PV LV 1 PE

13 Department of Computer Sciences, University of Wisconsin Madison LVM design PV LE LV 1 LV2 PE

14 Department of Computer Sciences, University of Wisconsin Madison LVM design PV LE LV 1 LV2 PE

15 Department of Computer Sciences, University of Wisconsin Madison LVM design VG PV LE LV 1 LV2 PE

16 Department of Computer Sciences, University of Wisconsin Madison DM design Userspace Applications logkcopyd emc ioctl interface filesystem interface control interfaceblock interface core device-mapper mapping/target interface linearstripedsnapshotmultipath round-robin path selectors hardware handlers

17 Department of Computer Sciences, University of Wisconsin Madison LVM – DM interaction Kernel Userspace Device Mapper libdevmapper LVM2

18 Department of Computer Sciences, University of Wisconsin Madison Outline Introduction Existing Framework Implementation Issues Results Conclusions

19 Department of Computer Sciences, University of Wisconsin Madison Modifications A trap mechanism from kernel driver to user- level LVM code. Support for multiple segments in LV Support for virtual mappings in driver

20 Department of Computer Sciences, University of Wisconsin Madison Initial State LVM Device Mapper User space Kernel space Unallocated Disk Space LVM daemon

21 Department of Computer Sciences, University of Wisconsin Madison Volume Group Creation LVM Device Mapper User space Kernel space Unallocated Disk Space LVM daemon PE (4MB) 25 Extents

22 Department of Computer Sciences, University of Wisconsin Madison Current Implementation LVM Device Mapper User space Kernel space Free Disk Space LVM daemon Create LV 32MB User A

23 Department of Computer Sciences, University of Wisconsin Madison Current Implementation LVM Device Mapper User space Kernel space Free Disk Space LVM daemon User A Map 0-7 extents for user A

24 Department of Computer Sciences, University of Wisconsin Madison Current Implementation LVM Device Mapper User space Kernel space Free Disk Space LVM daemon User A Map 0-7 extents for user A

25 Department of Computer Sciences, University of Wisconsin Madison Current Implementation LVM Device Mapper User space Kernel space Free Disk Space LVM daemon User A User B Create LV 16 MB

26 Department of Computer Sciences, University of Wisconsin Madison Current Implementation LVM Device Mapper User space Kernel space Free Disk Space LVM daemon User A User B Create LV 16 MB map 8-11 extents for B

27 Department of Computer Sciences, University of Wisconsin Madison Current Implementation LVM Device Mapper User space Kernel space Free Disk Space LVM daemon User A User B map 8-11 extents for B

28 Department of Computer Sciences, University of Wisconsin Madison Current Implementation LVM Device Mapper User space Kernel space Free Disk Space LVM daemon User A User B Read/write

29 Department of Computer Sciences, University of Wisconsin Madison Volume Group Creation LVM Device Mapper User space Kernel space Unallocated Disk Space LVM daemon PE (4MB) 25 Extents

30 Department of Computer Sciences, University of Wisconsin Madison Current Implementation LVM Device Mapper User space Kernel space Free Disk Space LVM daemon Create LV1 32MB User A

31 Department of Computer Sciences, University of Wisconsin Madison Current Implementation LVM Device Mapper User space Kernel space Free Disk Space LVM daemon User A Virtually map 0-7 extents for user A {0-7 error}

32 Department of Computer Sciences, University of Wisconsin Madison Current Implementation LVM Device Mapper User space Kernel space Free Disk Space LVM daemon User A User B Create LV 16 MB {0-7 error}

33 Department of Computer Sciences, University of Wisconsin Madison Current Implementation LVM Device Mapper User space Kernel space Free Disk Space LVM daemon User A User B Create LV2 16 MB Virtually map 8-11 extents for B {0-7 error} {8-11 error}

34 Department of Computer Sciences, University of Wisconsin Madison Current Implementation LVM Device Mapper User space Kernel space Free Disk Space LVM daemon User A User B {0-7 error} {8-11 error} Write 6MB

35 Department of Computer Sciences, University of Wisconsin Madison Current Implementation LVM Device Mapper User space Kernel space Free Disk Space LVM daemon User A User B {0-7 error} {8-11 error} write trap

36 Department of Computer Sciences, University of Wisconsin Madison Current Implementation LVM Device Mapper User space Kernel space Free Disk Space LVM daemon User A User B {0-7 error} {8-11 error} write trap On Demand allocation of disk area

37 Department of Computer Sciences, University of Wisconsin Madison Current Implementation LVM Device Mapper User space Kernel space Free Disk Space LVM daemon User A User B {0-7 error} {8-11 error} Write 6MB trap On Demand allocation of disk area Allocate 2 extents (8MB)

38 Department of Computer Sciences, University of Wisconsin Madison Current Implementation LVM Device Mapper User space Kernel space Free Disk Space LVM daemon User A User B {0-1 linear}{2-7 error} {8-11 error} Write 6MB trap On Demand allocation of disk area Allocate 2 extents (8MB)

39 Department of Computer Sciences, University of Wisconsin Madison Current Implementation LVM Device Mapper User space Kernel space Free Disk Space LVM daemon User A User B {0-1 linear}{2-7 error} {8-11 error} Write 10MB

40 Department of Computer Sciences, University of Wisconsin Madison Current Implementation LVM Device Mapper User space Kernel space Free Disk Space LVM daemon User A User B (0-1 linear}{0-7 error} {8-11 error} Write 10 MB trap

41 Department of Computer Sciences, University of Wisconsin Madison Current Implementation LVM Device Mapper User space Kernel space Free Disk Space LVM daemon User A User B {0-7 error} {8-11 error} write trap On Demand allocation of disk area

42 Department of Computer Sciences, University of Wisconsin Madison Current Implementation LVM Device Mapper User space Kernel space Free Disk Space LVM daemon User A User B {0-1 linear}{2-7 error} {8-10 linear} Write 10 MB trap On Demand allocation of disk area Allocate 3 extents (12 MB) {11 error}

43 Department of Computer Sciences, University of Wisconsin Madison Outline Introduction Existing Framework Implementation Issues Results Conclusions

44 Department of Computer Sciences, University of Wisconsin Madison Issues Not the most efficient implementation On a trap, How much to allocate? On demand Pre-allocate Where to allocate? Temporal locality Spatial locality Free unused space

45 Department of Computer Sciences, University of Wisconsin Madison How much? On-demand Allocate only as many blocks as needed Pre-allocate Pre-allocate physical space for blocks likely to be accessed in the future. How much? Where?

46 Department of Computer Sciences, University of Wisconsin Madison How much? Tradeoff – Performance vs. Disk Space Depends on the workload I/O on critical path Asynchronous I/O Multithreaded Applications

47 Department of Computer Sciences, University of Wisconsin Madison Pre-Allocation Think: Filesystem Block Allocation Dumb Allocation Stride Allocation Multi-Strided Allocation

48 Department of Computer Sciences, University of Wisconsin Madison Dumb Allocation LVM Device Mapper User space Kernel space Free Disk Space LVM daemon User A {0-1 linear}{2-7 error} Write 6MB trap On Demand allocation of disk area Allocate 2 extents (8MB)

49 Department of Computer Sciences, University of Wisconsin Madison Stride Allocation LVM Device Mapper User space Kernel space Free Disk Space LVM daemon User A {0-1 linear}{2-7 error} Write 6MB trap On Demand allocation of disk area Allocate 4 extents (16MB) PreAllocated Extent

50 Department of Computer Sciences, University of Wisconsin Madison Ext2 access pattern

51 Department of Computer Sciences, University of Wisconsin Madison Ext3 access pattern

52 Department of Computer Sciences, University of Wisconsin Madison Outline Introduction Existing Framework Implementation Issues Results Conclusions

53 Department of Computer Sciences, University of Wisconsin Madison Results Micro Benchmarks mkfs Trace based analysis Trace collected by HP Research Lab

54 Department of Computer Sciences, University of Wisconsin Madison Micro Benchmark : mkfs

55 Department of Computer Sciences, University of Wisconsin Madison Micro Benchmark : Asynchronous I/O

56 Department of Computer Sciences, University of Wisconsin Madison Micro Benchmark : Asynchronous I/O

57 Department of Computer Sciences, University of Wisconsin Madison Trace Based Analysis

58 Department of Computer Sciences, University of Wisconsin Madison Trace Based Analysis

59 Department of Computer Sciences, University of Wisconsin Madison Outline Introduction Existing Framework Implementation Issues Results Conclusions

60 Department of Computer Sciences, University of Wisconsin Madison Conclusions Tradeoff between performance penalty and space Useful in environments where space is the bottleneck resource Techniques like Pre Allocation reduce the performance penalty to some extent For practical implementation, LVM must be placed in kernel address space

61 Department of Computer Sciences, University of Wisconsin Madison Conclusions mkfs performance degrades substantially due to traps. No degradation in performance for CPU intensive applications with asynchronous I/O Extent size in the range of 512K-1M provide best results for the trace This evaluation will be more realistic, if LVM is moved into Kernel Address space.

Download ppt "Department of Computer Sciences, University of Wisconsin Madison DADA – Dynamic Allocation of Disk Area Jayaram Bobba Vivek Shrivastava."

Similar presentations

Live migration of Virtual Machines Nour Stefan, SCPD.

Live migration of Virtual Machines Nour Stefan, SCPD.
Principles of I/O Hardware I/O Devices Block devices, Character devices, Others Speed Device Controllers Separation of electronic from mechanical components.

Principles of I/O Hardware I/O Devices Block devices, Character devices, Others Speed Device Controllers Separation of electronic from mechanical components.
Full-System Timing-First Simulation Carl J. Mauer Mark D. Hill and David A. Wood Computer Sciences Department University of Wisconsin—Madison.

Full-System Timing-First Simulation Carl J. Mauer Mark D. Hill and David A. Wood Computer Sciences Department University of Wisconsin—Madison.
Department of Computer Science and Engineering University of Washington Brian N. Bershad, Stefan Savage, Przemyslaw Pardyak, Emin Gun Sirer, Marc E. Fiuczynski,

Department of Computer Science and Engineering University of Washington Brian N. Bershad, Stefan Savage, Przemyslaw Pardyak, Emin Gun Sirer, Marc E. Fiuczynski,
XEN AND THE ART OF VIRTUALIZATION Paul Barham, Boris Dragovic, Keir Fraser, Steven Hand, Tim Harris, Alex Ho, Rolf Neugebauer, lan Pratt, Andrew Warfield.

XEN AND THE ART OF VIRTUALIZATION Paul Barham, Boris Dragovic, Keir Fraser, Steven Hand, Tim Harris, Alex Ho, Rolf Neugebauer, lan Pratt, Andrew Warfield.
Storage Systems: Advanced Topics Learning Objectives: To understand limitations of “one file system per partition” model To understand Logical Volume Management.

Storage Systems: Advanced Topics Learning Objectives: To understand limitations of “one file system per partition” model To understand Logical Volume Management.
OS Memory Addressing.

OS Memory Addressing.
Allocation Methods - Contiguous

Allocation Methods - Contiguous
L V M A Logical Volume Manager for Linux by Heinz Mauelshagen Sistina, Inc.

L V M A Logical Volume Manager for Linux by Heinz Mauelshagen Sistina, Inc.
CMPT 300: Final Review Chapters 8 – 12. 2 Memory Management: Ch. 8, 9 Address spaces Logical (virtual): generated by the CPU Physical: seen by the memory.

CMPT 300: Final Review Chapters 8 – Memory Management: Ch. 8, 9 Address spaces Logical (virtual): generated by the CPU Physical: seen by the memory.
An Adaptable Benchmark for MPFS Performance Testing A Master Thesis Presentation Yubing Wang Advisor: Prof. Mark Claypool.

An Adaptable Benchmark for MPFS Performance Testing A Master Thesis Presentation Yubing Wang Advisor: Prof. Mark Claypool.
File Management Systems

File Management Systems
INTRODUCTION OS/2 was initially designed to extend the capabilities of DOS by IBM and Microsoft Corporations. To create a single industry-standard operating.

INTRODUCTION OS/2 was initially designed to extend the capabilities of DOS by IBM and Microsoft Corporations. To create a single industry-standard operating.
CMPT 300: Final Review Chapters 8 – 14. 2 Memory Management: Ch. 8, 9 Address spaces Logical (virtual): generated by the CPU Physical: seen by the memory.

CMPT 300: Final Review Chapters 8 – Memory Management: Ch. 8, 9 Address spaces Logical (virtual): generated by the CPU Physical: seen by the memory.
Chapter 12 File Management Systems

Chapter 12 File Management Systems
Silberschatz, Galvin and Gagne  2002 3.1 Operating System Concepts Common System Components Process Management Main Memory Management File Management.

Silberschatz, Galvin and Gagne  Operating System Concepts Common System Components Process Management Main Memory Management File Management.
Virtualization and the Cloud

Virtualization and the Cloud
Operating Systems Concepts 1. A Computer Model An operating system has to deal with the fact that a computer is made up of a CPU, random access memory.

Operating Systems Concepts 1. A Computer Model An operating system has to deal with the fact that a computer is made up of a CPU, random access memory.
Xen and the Art of Virtualization. Introduction  Challenges to build virtual machines Performance isolation  Scheduling priority  Memory demand  Network.

Xen and the Art of Virtualization. Introduction  Challenges to build virtual machines Performance isolation  Scheduling priority  Memory demand  Network.
Storage System: RAID Questions answered in this lecture: What is RAID? How does one trade-off between: performance, capacity, and reliability? What is.

Storage System: RAID Questions answered in this lecture: What is RAID? How does one trade-off between: performance, capacity, and reliability? What is.

Similar presentations

Ads by Google