Download presentation
Presentation is loading. Please wait.
Published byVivian Foster Modified over 9 years ago
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
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.