1. Hot and Cold Data Identification -Applications to Storage Devices and Systems- Dongchul Park Computer Science and Engineering July 16, 2012 Advisor: Professor David H.C. Du Ph.D. Final Defense

2. Agenda  Introduction  Proposed hot data identification scheme  Multiple bloom filter-based design  Applications to storage  SSD (Solid State Drive) design  Data deduplication system  Conclusion 2

3. Introduction  What are hot data?  Data that have been frequently accessed so far (Past)  Data that will be frequently accessed in the near future (Future)  In storage systems, hot data identification has a critical impact on  The performance (Most Storage)  The reliability (i.e., lifespan) (Flash-based SSD)  Diverse applications  Flash memory, cache algorithms, hybrid SSD, shingled write disks, data deduplication systems, etc.  Least investigated issue 3

4. Overview  Exploration  Investigate existing hot data identification schemes  Design  Propose a novel hot data identification design  Applications  Apply our scheme to a storage devices or system Solid State Drive (SSD) design Data deduplication system  Observe how to get over the existing limitations in storage systems 4

5. 5 Hot Data Identification Scheme (Multiple BF-based Hot Data Identification) ● Dongchul Park and David H.C. Du. “Hot Data Identification for Flash-based Storage Systems using Multiple Bloom Filters,” In Proceedings of the 27th IEEE Symposium on Mass Storage Systems and Technologies (MSST ’11), Denver, CO, USA, May 23-27, 2011.

6. Introduction  Hot data  Definition can be different from each application  Data that will be frequently accessed in the near future Similar to a prediction concept Possible applications: data cache, flash memory  High-level goal  How to efficiently predict hot data based on access history information?  How to quantitatively define hot data? Frequency information Recency information 6

7. Existing work  Two-level LRU  Maintains a hot list and candidate list Operates under LRU algorithm Save memory space  Performance is sensitive to the sizes of both lists  High computational overhead 7

8. Existing work  Multi-hash function scheme  Adopts multiple hash functions One bloom filter with D-bit counter Decay after a specific period Save memory space and computational overhead  Cannot capture recency well Exponential batch decay 8

9. Observation  Requirements for efficient hot data identification  Effective capturing of recency information as well as frequency information  Small memory consumption  Low runtime overheads  Multiple bloom filter-based scheme 9

10. Multi-BF Hot Data Identification  Objective  How to efficiently capture both recency information and frequency information?  Architecture  Multiple bloom filters (BF) To capture finer-grained recency To reduce memory space and overheads  Multiple hash functions To reduce false identification  Key idea  Assign different recency weight to each BF Each BF retains different recency coverage 10

11. 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 h1h1 h1h1 h2h2 h2h2 X 0 0 0 0 0 0 0 0 0 0 0 0 0 YZ BF 1 BF 2 BF 3 BF V … 1 1 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 1 1 A A Basic operations 11

12. Capturing Frequency  No access counters  Needs a different mechanism  For frequency capturing  Chooses one of BFs in a round-robin manner  If the chosen BF has already recorded the LBA Records to another BF available.  Shortcut decision If all BFs store the LBA information – Simply define the data as hot  The Number of BF can provide frequency information 12

13. Capturing Recency  After a decay period (T)  Choose one of V-BFs in a round-robin manner  Erase all information (i.e., reset all bits to 0)  Each BF retains a different recency coverage. 13

14. Recency Coverage  For finer-grained recency  Each BF covers a different recency coverage The reset BF (BF v ): Shortest (latest) coverage The next BF (BF 1 ): Longest (oldest) coverage  Each BF has a different recency value 14

15. Performance Evaluation  Evaluation setup  Four schemes Multiple bloom filter scheme (refer to as MBF) Multiple hash function scheme (refer to as MHF) Direct Address Method (refer to as DAM) Window-based Direct Address Counting (refer to as WDAC)  Four realistic workloads Financial1, MSR (prxy volume 0), Distilled, and RealSSD 15 MSST 2011

16. False Identification Rates 16 (b) MSR(a) Financial1  Our scheme (MBF) shows an even lower false identification rate than multi-hash scheme (MHF)  A Longer decay period in MHF causes a higher false rate

17. Memory Impact & Computational Overheads 17  Our scheme (MBF) shows a better performance  Consumes less memory spaces  Lower computational overhead

18. Summary  Multiple BF-based hot data identification  Adopts multiple BFs and hash functions  Can capture finer-grained recency  Shows better performance than multi-hash function scheme 18

19. Applications to Storage Devices and Systems (SSD & Data Deduplication System)

20. 20 [1] Application to Solid State Drive Design ● Dongchul Park, Biplob Debnath and David H.C. Du. CFTL: A Convertible Flash Translation Layer Adaptive to Data Access Patterns. In Proceedings of ACM SIGMETRICS international conference on Measurement and Modeling of computer systems (SIGMETRICS '10), New York, NY, USA, June 14-18, 2010. ● Dongchul Park, Biplob Debnath and David H.C. Du. A Workload-Aware Adaptive Hybrid Flash Translation Layer with an Efficient Caching Strategy. In Proceedings of the 19th IEEE International Symposium on Modeling, Analysis and Simulations of Computer and Telecommunication Systems (MASCOTS ’11), Singapore, July 25-27, 2011.

21. Motivations  Benefits over magnetic hard drives  Semi-conductor technology, no mechanical parts  Offers lower and more predictable access latencies μs (25 μs Reads / 200 μs Writes) vs. ms for magnetic  Lower power consumption  Higher robustness to vibrations and temperature  Dropping prices  Some projections suggest comparable with magnetic by 2017  Likely to offer significant cost advantage over other emerging technologies (e.g., PCM) for a decade or more 21

22. Motivations  However, some key shortcomings …  Slow writes Writes 4-8 times slower than reads  Erase operations Writes require erases which degrade performance  Reliability (limited lifespan) Cells become unreliable as they are erased more and more Goal: Improve handling of writes/erases 22

23. Basics of NAND Flash Memory  Three operations: read, write, erase  Asymmetric operational unit and performance  Reads and writes: page basis (25 μs Reads / 200 μs Writes)  Erases: block basis (2 ms)  Overwriting (in-place update) is not allowed  Updating can only be done after erase (erase-before-write) 23 Page Block Page DataOOB Block …… Page DataOOB Block …… NAND Flash Page Data OOB …… Page Data OOB …… Page

24. Out-of-Place Update  Overwrites on the same location (page) are expensive  Updates are written to a free (clean) page  OOB (Out Of Band) area  Keeps valid/free/invalid status  Stores LPN, used to reconstruct mapping table upon power failure 24 (0, 0) Block 0 Flash Mapping Table A LPNPPN (PBN, Offset) B(0, 1) C(0, 2) (0, 3) A Update Free LPN=A, V LPN=B, V LPN=C, V DataOOB InvalidLPN=A, V

25. Architecture of Flash-based Storage 25 Application 1Application 2 Application 3 File Systems Memory Technology Device Layer Flash Memory SRAM (DRAM) Garbage Collector Wear leveler Wear leveler fwrite (file, data) block write (LBA, size) Flash write (block, page) control signal Flash Translation Layer (FTL) … Hot Data Identifier Hot Data Identifier Address Allocator

26. Flash Translation Layer (FTL)  Flash Translation Layer  Emulates a block device interface  Hides the presence of erase operation/erase-before-write  Address translation, garbage collection, and wear-leveling  Address Translation  Three types: Page-level, block-level, and hybrid mapping  Mapping table is stored in a small RAM within the flash device 26

27. Page vs. Block Level Mapping 27 Page Logical Address : LPNPhysical Address : PPNPage Level FTLBlocks PPN Page Level MappingBlock Level Mapping Page Logical Address : LPNBlock Level FTLBlocks PBN LBNOffsetPBNOffset Flexible but requires a lot of RAM (e.g., 2MB for 1GB SSD) Less RAM (e.g., 32K for 1GB SSD), but inflexible in content placement

28. 28 Hybrid FTLs Page Level FTL Page Data Blocks Page Log Blocks Flash Block Level FTL Logical Address: LPN PBN LBNOffsetPBNOffset Logical Address : LPNPhysical Address : PPN PPN Request : Write LPN ‘X’ Request : Update LPN ‘X’ Can we develop an FTL which can dynamically change its mapping scheme?

29. 29 DataOOB LPN=2, I LPN=3, I LPN=1, I LPN=0, I Data Block A Merge Operations Log Block B Data OOB LPN=3, V LPN=0, V LPN=1, V LPN=2, V Erase Free Block Data OOB LPN=2, V LPN=3, V LPN=1, V LPN=0, V Data Block A Switch Merge LPN=3, V LPN=0, I LPN=1, I LPN=2, V DataOOB Data Block A Free LPN=0, V LPN=1, V Free DataOOB Log Block B Partial Merge LPN=3, V LPN=0, V LPN=1, V LPN=2, V DataOOB LPN=2, V LPN=3, V LPN=2, I LPN=3, I Erase Free BlockData Block A Overhead = 1 Block Erase Overhead = 1 Block Erase + 2 Valid Page Copies

30. 30 Full Merge Operation LPN=12, I LPN=0, V LPN=5, V LPN=9, I DataOOB LPN=6, V LPN=82, V LPN=30, V LPN=2, V DataOOB LPN=4, V LPN=91, V LPN=1, V LPN=20, V DataOOB LPN=3, V LPN=0, I LPN=1, I LPN=2, I DataOOB LPN=7, V LPN=4, I LPN=5, I LPN=6, I DataOOBDataOOB Log Block L1 (Victim) Log Block L2Log Block L3 Data Block D1 Data Block D2 Erased Block LPN=0, V LPN=1, V LPN=2, V LPN=3, V LPN=3, ILPN=0, ILPN=1, ILPN=2, I Erase LPN=0, V LPN=1, V LPN=2, V LPN=3, V LPN=4, V LPN=5, V LPN=6, V LPN=7, V LPN=5, ILPN=4, ILPN=6, I Erase LPN=4, V LPN=5, V LPN=6, V LPN=7, V Erase Overhead = 3 Block Erases + 8 Valid Page Copies Can we develop an FTL which can completely remove full-merge operations?

31. Temporal and Spatial Localities  Temporal locality  For the Financial trace, about 80% of the accesses belong to first 5000 requests in the LRU stack.  Spatial locality? 31 Financial Trace Cumulative Probability of Virtual Address Access Frequency Can we develop an FTL which can make the best use of a limited memory space?

32. Related Work (Existing FTLs)  Hybrid Mapping FTL  BAST (Block Associative Sector Translation) Log buffer-based scheme Limitation: log block thrashing  FAST (Fully Associative Sector Translation) Log blocks  random + sequential Limitation: full merge operations  AFTL (Adaptive Two-level Flash Translation Layer) LRU information  block mapping / MRU information  page mapping Limitation: significant overhead of valid data copy  Page Level Mapping FTL  DFTL (Demand-based page level FTL) Two-level address translation Limitation: address translation overhead  low read performance  Main goal: try to reduce merge (erase) operations 32

33. CFTL: An Adaptive Hybrid FTL  CFTL (Convertible Flash Translation Layer)  Hybrid mapping Fundamentally based on a page level mapping.  Adaptive scheme Hot/Cold data identification Dynamically switches to either scheme according to data access patterns.  Efficient caching strategy Exploit spatial locality (as well as temporal locality). 33

34. CFTL Architecture 34 Consecutiveness information of PPNs in Tier-2 page mapping tables is stored to a consecutive field in CPMT to exploit spatial localities.

35. Address Translation Process 35 M VPN M PPN 021 117 215 322 Tier-1 Index Table Data Block M PPN = 15 M VPN = 2 Valid LPNPPN 1024570 -- 1280660 1281661 1535420 M PPN = 21 M VPN = 0 Valid LPNPPN 0110 1130 2131 3132 511560 1/ 512 = 0 1130 DATA D LPN =1280 Valid D PPN = 660 OOB PPN = 661 Mapping Table Block (Tier-2 page mapping tables) 131 1280/512 = 2 1280660 DATA LPN=1280 Valid PPN = 660 M PPN = 131 M VPN = 0 Valid D LPN D PPN 0110 1260 2440 -- 511560 M PPN = 130 M VPN = 3 Valid LPNPPN 1536900 1537901 1538902 1539903 2047780 Free LBNPBN 445 1258 730 4556 CBMT LPN = 1280 1280/64 = 20 Invalid CPMT LPN PPN 223150 1536900 11220 1130 CO 1 4 2 3 Victim 1260112806602 DATA

36. Addressing Mode Changes  Hot/Cold Data Identifier  Hot data: frequently updated  Cold data: not updated or accessed in a read manner  Adopts multiple BF-based scheme  Mode Changes  Page  Block Identified as cold data (i.e., read intensive data). Collect data pages into a block and register this block mapping information into CBMT.  Block  Page Identified as hot data (i.e., write intensive data). Simply erase the corresponding block mapping information from CBMT (Does not require any cost). 36

37. Efficient Caching Strategy  Consecutive Field  How many PPNs are consecutive? Maintain one more field in CPMT.  Provide a hint Even though cache miss occurs, this field helps to make the request hit the cache. Achieve higher address translation efficiency even with the same cache size.  Advantages  Exploit spatial locality as well as temporal locality  Improve cache hit ratio  Improve overall performance further 37

38. Performance Evaluation  Workloads 38 WorkloadsTotal RequestsCharacteristics (Read:Write)Inter-arrival Time Websearch34,261,709R: 4,260,449 (99%) W: 1,260 (1%)70.093 ms Financial15,334,987R: 1,235,633 (22%) W: 4,099,354 (78%)8.194 ms Financial23,699,194R: 3,046,112 (82%) W: 653,082 (18%)11.081 ms Random_read3,695,000R: 3,657,822 (99%) W: 37,170 (1%)11.077 ms Random_even3,695,000R: 1,846,757 (50%) W: 1,848,244 (50%)11.077 ms Random_write3,695,000R:370,182 (10%) W: 3,324,819 (90%)11.077 ms  Simulated FTLs  Ideal – A pure page-based FTL scheme assuming infinite RAM  FAST – Fully Associative Sector Translation hybrid FTL  DFTL – Demand-based Page mapped FTL  AFTL – LRU-based Two-level FTL

39. Overall Performance 39 (a) Read intensive (99% Read : 1% Write) (c) Write intensive (10% Read : 90% Write) (b) Random_read_intensive (90% Read : 10% Write)  CFTL outperforms other FTLs  Close to the ideal page level mapping performance  DFTL shows a good write performance  FAST shows a good read performance

40. Performance Improvement (our caching strategy: consecutive field) 40  CFTL caching strategy significantly improve performance  In particular, read intensive workloads

41. Summary  CFTL (Convertible FTL)  Adaptive to data access patterns  Efficient caching strategies Consecutive field and adaptive partitioning  Experimental results  Overall performance CFTL outweighs competitors (vs. DFTL) – Random read-intensive workload: Up to 47%  Cache hit ratio Up to 400%: Read intensive workload (Websearch)  Memory impact Better performance with the same amount of RAM 41

42. 42 [2] Application to Data Deduplication System

43. Introduction  Data deduplication (Dedupe)  A method of reducing storage needs by eliminating redundant data  Only one unique instance of the data is retained on storage media  Redundant data is replaced with a pointer to the unique data copy  Significantly save storage space, and improve write performance  Data compression vs. Dedupe  Data compression can reduce the data size by eliminating a redundant bit  However, it cannot detect or reduce multiple copies of the same data  Dedupe granularity  File, block, and byte-level 43

44. Example  Typical deduplication process 44 Data Stream a1 a0 A A Chunking Container Data Deduplication Box a1 a0 b1 b0 B B Deduplication b1 b0 Caching, Buffering B B Underlying Storage a1 a0 b0

45. Motivation  Read performance issue in dedupe  The higher dedupe ratio, the lower read performance Higher likelihood of the shared data fragmentation 45 400300 201200 13 12 11 10 11 10 13 12 200*** 201 ***300*** 400 Underlying Storage Container 100 Container 20 Container 30 Container 7 Incoming chunks

46. Motivations  Data deduplication (Dedupe)  Traditional dedupe research has focused mainly on its write performance improvement Original goal: to save storage consumption  As duplicated data increases, its read performance decreases  Dedupe with high read performance  Little attention has been drawn, but very important Recovering an entire system from crash Application to primary storage 46

47. Motivations  For typical chunk read processes in dedupe storage  Identify its data container ID retaining the chunk  Look up the container in the read cache  If cache miss, evict one chunk with LRU from the cache and read the container from the dedupe storage  Read the chunk from the cache  Limitations  Many containers in the read cache are poorly utilized.  Not exploiting the future access patterns 47

48. Overview  Main objective  To improve the read performance in dedupe storage  Key ideas  Exploiting future access patterns  Managing a small log buffer  Assumption  Access unit for dedupe read is a data container That is, caching unit is a data container Dedupe system cannot directly access data chunks in the storage  Basic cache policy  Choose a victim with a smallest future access count 48

49. 49 Architecture (Base design) 212231232441422526325127... 43 Moving Window Current data chunk to read Hash_Function (Container_ID(Chunk_ID)) ------2 Hot Data Identification HOT Container 1 HOT Container 1 HOT Container 2 HOT Container 2 COLD Container N COLD Container N Read Cache … … Hot/Cold? Data Container Reference Counters 30... - 721

50. Hot Data Identification  Architecture  A counting bloom filter: To efficiently capture frequency information  Multiple hash functions: To reduce a false identification possibility  Hot definition  Hot container: Over than 5% of data chunks in the container are accessed. This is based on our workload analysis 50

51. Hot Data Identification  Workload analysis  When we reach 5%, it accommodates most of the # of data container  Most data containers are accessed less than 5% 51 % of accessed data chunk in a container Fig: Distribution of the # of accessed data container

52. Managing Future Reference Count (come into future window) 52 h1h1 h3h3 0 1 0 0 0 0 0 1 0 1 0 0 1 1 0 0 0 0 0 1 0 1 0 0 0 0 0 0 0 1 0 0 0 0 1 0 0 0 1 0 0 1 0 1 0 1 0 0 1 0 1 0 0 1 0 0 0 1 1 1 3132... Hot/Cold Data Identification Data Chunks +1 352622... Future Window Current Access 43 h2h2 0101 +1

53. Managing Future Reference Count (evicted from future window) 53 h1h1 h3h3 0 1 0 0 0 0 0 1 0 1 0 0 1 1 0 0 0 0 0 1 0 1 0 0 0 0 0 0 0 1 0 0 0 0 1 0 0 0 1 0 0 1 0 1 0 1 0 0 1 0 1 0 0 1 0 0 0 1 1 1 3141... Hot/Cold Data Identification Data Chunks 35 2622... Future Window Current Access 33 h2h2 0101

54. Overall Process 54 h1h1 h3h3 0 1 0 0 0 0 0 1 0 1 0 0 1 1 0 0 0 0 0 1 0 1 0 0 0 0 0 0 0 1 0 0 0 0 1 0 0 0 1 0 0 1 0 1 0 1 0 0 1 0 1 0 0 1 0 0 0 1 1 1 222131 41... H/CH/C H/CH/C HOT ID:4 Cold ID:3 Cold ID:3... Read Cache Hot/Cold Data Identification Data Chunks to read Moving Window Hash Functions Current Access h2h2 1101 Smallest Count HOT ID:2 (1)We need to store a data container retaining the chunk 41 into the cache (2) We choose a container with a smallest future reference count

55. Design Extension  Key ideas  A Small Log Buffer Maintain the remaining future access chunks in a cold container (i.e., victim) to a log buffer before eviction.  Victim selection  Choose a container with a smallest future reference count  Cold container: store future access chunks into the log buffer  Hot container: just evict it without buffering any chunks To prevent cache contamination

56. Design Extension  Enhanced Architecture 56 Log Buffer 1 1 2 2 1 1 2 2 Read Cache Tag: HOT Container 1 Tag: HOT Container 1 Tag: COLD Container N Tag: COLD Container N … … … … Victim: coldest (Logging future access data chunks) If this victim is COLD, Move to the log buffer 4 4 4 4 H/C

57. Experimental Results  Workloads  Simulated cache schemes  Our base design  Our extended design  LRU (Least Recently Used) 57 Dataset# of ChunksAvg. DGRTotal size# of version DS-11,970,8360.2920GB5 DS-21,960,5550.3720GB5 DS-31,951,2710.9720GB5 DS-41,892,2850.5020GB5 DS-51,922,4200.2020GB5 DS-6771,4650.388GB2

58. Evaluation Results  Our base design vs. LRU 58  Our base design shows better read performance than LRU with the same cache space  Our design exploits future access information

59. Evaluation Results  Our base design vs. extended design 59  Our extended design shows better performance than our base design. (Base: base design, Thr: extended design with various hot thresholds  In particular, it shows much better performance in DS-5 trace

60. Summary  Read cache design for a dedupe system  Exploit future access patterns  A Log buffer design  Performance evaluation  Better performance than LRU  Log buffer scheme helps improve read performance further  Performance gain is dependent on workload characteristics 60

61. Conclusion  Hot data identification  Important in storage systems  Applicable to diverse computer systems  Proposed schemes  Multiple-BF scheme  Applications  SSD design  Data deduplication system 61

62. Publications  Dongchul Park, Biplob Debnath and David H.C. Du. CFTL: A Convertible Flash Translation Layer Adaptive to Data Access Patterns. In Proceedings of ACM SIGMETRICS international conference on Measurement and Modeling of computer systems (SIGMETRICS '10), p.365-366, New York, NY, USA, June 14-18, 2010.  Dongchul Park and David H.C. Du. Hot Data Identification for Flash-based Storage Systems using Multiple Bloom Filters. In Proceedings of the 27th IEEE Symposium on Mass Storage Systems and Technologies (MSST '11), p.1-11, Denver, CO, USA, May 23-27, 2011.  Dongchul Park, Biplob Debnath and David H.C. Du. A Workload-Aware Adaptive Hybrid Flash Translation Layer with an Efficient Caching Strategy. In Proceedings of the 19th IEEE International Symposium on Modeling, Analysis and Simulations of Computer and Telecommunication Systems (MASCOTS '11), p.248-255, Singapore, July 25-27, 2011.  Youngjin Nam, Dongchul Park and David H.C. Du. Virtual USB Drive: A Key Component for Smart Home Storage Architecture. In Proceedings of the 30th IEEE International Conference on Consumer Electronics (ICCE '12), Las Vegas, USA, January 13-16, 2012.  Dongchul Park, Biplob Debnath, Youngjin Nam, David H.C. Du, Youngkyun Kim and Youngchul Kim. HotDataTrap: A Sampling-based Hot Data Identification Scheme for Flash Memory. In Proceedings of the 27th ACM Symposium on Applied Computing (SAC '12), p.759-767, Italy, March 26-30, 2012.  Young Jin Nam, Dongchul Park and David H.C. Du. Assuring Demanded Read Performance of Data Deduplication Storage with Backup Datasets. In Proceedings of the 20th IEEE International Symposium on Modeling, Analysis and Simulations of Computer and Telecommunication Systems (MASCOTS '12), Arlington, VA, USA, August 7-9, 2012  Chung-I Lin, Dongchul Park, Weiping He and David H.C. Du. H-SWD: Incorporating Hot Data Identification into Shingled Write Disks. In Proceedings of the 20th IEEE International Symposium on Modeling, Analysis and Simulations of Computer and Telecommunication Systems (MASCOTS '12), Arlington, VA, USA, August 7-9, 2012..  Dongchul Park, Young Jin Nam and David H.C. Du. A Lookahead Read Cache: Improving Read Performance of Deduplication Storage for Backup Applications. The 4th USENIX Workshop on Hot Topics in Storage and File Systems (HotStorage '12), Boston, MA, USA, June 13-14, 2012. (submitted)  Dongchul Park, Biplob Debnath and David H.C. Du. CFTL: A Adaptive Hybrid Flash Translation Layer with Efficient Caching Strategies. IEEE Transactions on Computers, June, 2012 (Under revision). 62

63. Questions? Dongchul Park park@cs.umn.edu

64. 64 Backup Slides

65. container Backup Data Stream Backup Data Stream Underlying Storage 65 Typical Deduplication Typical Deduplication Selective Duplication Selective Duplication In-memory Container In-memory Container In-memory Temp Container In-memory Temp Container container Cache-aware CFL Monitor Cache-aware CFL Monitor switch Selective duplication CFL req Threshold (p) ● Young Jin Nam, Dongchul Park and David H.C. Du. Assuring Demanded Read Performance of Data Deduplication Storage with Backup Datasets. In Proceedings of the 20th IEEE International Symposium on Modeling, Analysis and Simulations of Computer and Telecommunication Systems (MASCOTS '12), Arlington, VA, USA, August 7-9, 2012.

66. Memory Impact 66 (a) Websearch3 (99% Read : 1% Write) (b) Random_even (50% Read : 50% Write)  CFTL requires a less memory space  Show a better performance with the same memory space  Approach to the page level mapping performance faster Normalized in terms of a page level mapping

67. Hot Ratios (MBF vs. MHF vs. WDAC vs. DAM) 67 (b) MSR(a) Financial1

68. Workload Characteristics 68  DS-1: as version # increases, its shared chunks also increases  The first version rarely contains shared data chunks (sequential accesses)  DS-6: even first version contains lots of shared data chunks